Question; XML element order for complex elements with prodat

Look up the Write-XML() method and NESTED

To get the optional field, I am sure that you will either have to post-filter the results or write your own equivalent of Write-XML().

Hmm thats not exactly what i meant

I know how the WRITE-XML works and the NESTED option. But i think its not possible to build an XML with a complex elements in the middle between simple elements. You can only put complex elements at the end (still nested and with nested you can put other complex elements in the previous one again also, works fine, but always after the simple elements. So now i wrote my own WRITE-XML version where i can do that.

Im a bit dissapointed in the limited abilities of mapping XML to datasets/temptables with WRITE-XML and READ-XML, unless the xml is extremely simple it seems pretty useless to me. Even the commandline tool wont generate include files for most schema's and give an errormessage saying something like cant map schema to dataset...So its back to writing it yrself with the sax reader/writer...

Or am i completely wrong ?

When I first heard about read- and write-xml methods, I thought cool, but it took me about 15 minutes to decide that there were notable limitations and it was awfully easy to write on oneself. Indeed, if one were properly using code generation, one wouldn't even have to do that. One of the pieces that got me was the header it insists on putting on. If one is trying to serialize a collection, then one has to strip out that header on all of the components before assembling it.

Frankly, it seems like one of those things where, by the time you put enough options on to cover all the bases, it would be so complex to use that one might as well just write the code.

How can i define it so that the xml would be like :

......

line>

I guess you want a more realistic version like:

when there is no DATA-RELATION between the temp-tables in the dataset.

Theo, i think yr missing the point.

The situation that u call more realistic is easy to make. But you show only tables in your example, and dont show any fields. Nesting tables isnt the problem. The problem is i cant state between which fields in table 1 i want to place table2.

example :

Example :

(i didnt testrun this, its just typing text)

define temp-table ttHeadline no-undo

FIELD ttHeadline_id AS INTEGER XML-NODE-TYPE "HIDDEN"

FIELD headfield1 AS CHARACTER

FIELD headfield2 AS CHARACTER

FIELD headfield3 AS CHARACTER

index ttHeadline_id is primary unique ttHeadline_id.

define temp-table ttSubine no-undo

FIELD ttSubline_id AS INTEGER XML-NODE-TYPE "HIDDEN"

FIELD ttHeadline_id AS INTEGER XML-NODE-TYPE "HIDDEN"

FIELD subfield1 AS CHARACTER

FIELD subfield2 AS CHARACTER

FIELD subfield3 AS CHARACTER

index ttSubline_id is primary unique ttSubline_id.

define dataset dsMydataset NAMESPACE-URI "http://something/somethingmore"

for ttHeadline , ttSubline

DATA-RELATION FOR ttHeadline , ttSubline RELATION-FIELDS (ttHeadline.ttHeadline_id, ttSubine.ttHeadline_id) NESTED

.

If you take this example code, WRITE-XML will generate something like this :

Without the nested option it would place ttsubline below ttheadline and not within, but thats not the problem here.

Then again, i already gave up on WRITE-XML, best way is to do make yr own WRITE-XML

So, would it be accurate to say that your problem is that in your case, the second table is conceptually a child of one of the fields in the first table, rather than a child of the record as a whole?

nopes its not a child of a field, normal child of table. But just cant say where in the xml result the subtable should be placed. If in the headline table you change the position of field2 and field 3, then in the output xml these are also in changed order. But you cant specify where in the output the subtable is placed.

Basicly what i wanna be able to do is say :

define temp-table ttHeadline no-undo

FIELD ttHeadline_id AS INTEGER XML-NODE-TYPE "HIDDEN"

FIELD headfield1 AS CHARACTER

FIELD headfield2 AS CHARACTER

FIELD dummy AS CHARACTER XML-NODE-TYPE "HIDDEN" HELP "INSERT CHILD TABLE ttSubline here"

FIELD headfield3 AS CHARACTER

index ttHeadline_id is primary unique ttHeadline_id.

Basicly what i wanna be able to do is say :

define temp-table ttHeadline no-undo

FIELD ttHeadline_id AS INTEGER XML-NODE-TYPE

"HIDDEN"

FIELD headfield1 AS CHARACTER

FIELD headfield2 AS CHARACTER

FIELD dummy AS CHARACTER XML-NODE-TYPE "HIDDEN"

HELP "INSERT CHILD TABLE ttSubline here"

FIELD headfield3 AS CHARACTER

index ttHeadline_id is primary unique ttHeadline_id.

Have you tried defining an XML-schema upfront and let the write-xml of the dataset use it? It should obey the schema...

What I am trying to get clear is why you want the subtable at that particular position. I.e., what is "natural" or "appropriate" about it being there rather than somewhere else?

The reason is simple; we already have quite a few xml messages in a certain layout; but the code used for it wasnt optimal so im looking at ways to re-write the code without changing our existing messages so our customers wont experience any changes except performace improvement.

Theo,

Sounds good, but if i look at WRITE-XML i can only enter schema parameters to generate a schema or write a schema location in the xml.

But you're saying that i can define a dataset with temptables and somehow tell WRITE-XML to use a schema file ??

Can you post a brief example of how to do that ?

But you're saying that i can define a dataset with

temptables and somehow tell WRITE-XML to use a schema

file ??

Can you post a brief example of how to do that ?

I can't test this, since I'm not actively programming ABL anymore, but as far as I can see, you should use READ-XML-SCHEMA() first to load an XML-schema and associate it with the ProDataSet. Next when you write the XML it should respect the schema. You can use the schema reference in the WRITE-XML to point to an external schema for the users of your XML. That's something else but it should of course match the schema the PDS is using

Well as far as i can see, it doesnt work like that

Would be nice, but with write-xml u cant specify which schema to obey, it takes a schema definition from the structure of the temp-tables. the readxml schema can only verify a schema against a static defined dataset/temptable, or create a dynamic one based on a xsd. And even then, there are many schema options that dont work with the read schema...

Ah well, tnx for trying