Sequence of XML elements

[LBurkett99]

I am working with a program which takes as input parsed XML data. When element <a> precedes element <b> in the XML document, everything works great. But when element <b> precedes element <a>, the value of element <a> is not captured.

Is the sequence of XML elements at the same level significant to the validity of the document? Or is the program deficient by capturing the value of <a> only when it precedes <b>?

There is no schema for this document.

[B.Hauser]

Could you be please more precisely?
How are you consuming the XML document? With RPG, with SQL?
How the XML document looks like?
Could you post what you have done so far.

Birgitta

[LBurkett99]

The following is a portion of an XML document submitted to create a sales order:

<LineItemInfo>
<ItemNumber></ItemNumber>
<LineItemType>/</LineItemType>
<ActualSellPrice>10.00</ActualSellPrice>
<ChargeType>W</ChargeType>
</LineItemInfo>

The <ChargeType> specifies a miscellaneous charge type of 'W' and the charge amount is $10.00.
The item is created as part of the order.


Here is the same portion of the document, but <ChargeType> precedes <ActualSellPrice>.

<LineItemInfo>
<ItemNumber></ItemNumber>
<LineItemType>/</LineItemType>
<ChargeType>W</ChargeType>
<ActualSellPrice>10.00</ActualSellPrice>
</LineItemInfo>

In this case the miscellaneous charge item is not created because the program says there is no amount.. This because the item is created when the <ChargeType> tag is recognized and its value processed, and in this case we have not yet recognized the <ActualSellPrice> tag.

My question is, are the elements of an XML document like the fields of a record, always in the same sequence? Or should a program be able to handle any sequence of elements, at least at the same level?

[Scott Klement]

Some XML documents require the elements in a particular order, and some do not. When there's a formal schema created for a document, you can choose in the schema when to enforce a particular sequence and when not to.

You've provided very little information about what is happening, so we can't help with this issue. If you want help, please tell us which software you are using to read the XML, and what you've tried that isn't working. Thanks!

[LBurkett99]

Thanks Scott.

If I understand you correctly, unless there is something which enforces a particular order, a program processing the data in an XML document needs to be able to handle the elements in any order. In my case the program is at fault since there is nothing that defines a particular order and the program produces a different result when the input is not in the order expected.

[JonBoy]

Thanks Scott.

If I understand you correctly, unless there is something which enforces a particular order, a program processing the data in an XML document needs to be able to handle the elements in any order. In my case the program is at fault since there is nothing that defines a particular order and the program produces a different result when the input is not in the order expected.

If you were to use RPG's XML-INTO it would take care of this automagically as indeed would using SQL's parsing capabilities.

How is the program currently handling it?

[LBurkett99]

The XML is parsed by a "black box". The earliest thing I can see is a user space. Entries in this user space are of the form element-name, parent-element-name, hierarchy-level, any value inside the tag (i.e.,'some-value' for <element-name some-value>, and element-value. Each of these five pieces are separated by a x'ab' and each entry is terminated with a x'64'. A x'00' terminates the data.

The RPG program calls a procedure which returns the five pieces of the each user space entry in an array. The program looks for specific values of array(1) and handles array(5) as appropriate. Data returned in successive calls are in the same sequence as the XML.

Tell me, how would XML-INTO or SQL parser take care of this? Rewriting the program using one of the methods is a possibility.

[JonBoy]

Tell me, how would XML-INTO or SQL parser take care of this? Rewriting the program using one of the methods is a possibility.

Birgitta will do a better job of demonstrating the SQL option than I so I'll just show the XML-INTO.

Here's a code sample (it works) based on your data.

dcl-s xml_source Char(350) Inz('<LineItems><LineItemInfo>+
                                 <ItemNumber></ItemNumber>+
                                 <LineItemType>/</LineItemType>+
                                 <ActualSellPrice>10.00</ActualSellPrice>+
                                 <ChargeType>W</ChargeType>+
                                 </LineItemInfo>+
                                 <LineItemInfo>+
                                 <ItemNumber></ItemNumber>+
                                 <LineItemType>/</LineItemType>+
                                 <ChargeType>W</ChargeType>+
                                 <ActualSellPrice>20.00</ActualSellPrice>+
                                 </LineItemInfo></LineItems>');

dcl-ds  LineItemInfo  Qualified  Dim(1000);
   ItemNumber        Char(8);
   count_ItemNumber  Int(3);
   LineItemType      Char(1);
   ActualSellPrice   Char(12);
   ChargeType        Char(1);
end-ds  LineItemInfo;

xml-into LineItemInfo %XML( xml_source: 'case=any countprefix=count_' );

*InLr = *On;

I noticed that ItemNumber was an empty element - not sure if it is empty in the original or simply omitted and the black-box fills it in - anyway I took the opportunity to show how you can tell whether an element was present or not by associating a count with the item. If a specific ItemNumber entry was present then count_ItemNumber would be 1 - if the element is omitted completely then it would be zero.

I "wrapped" your XML in a root element LineItems to make it valid XML.

If the XML is to come from a file (as opposed to a variable) then the XML-INTO changes to:

[FONT=courier new]xml-into LineItemInfo %XML( 'PathTowhereverYourXMLDateIs': 'case=any doc=file countprefix=count_' );[/FONT]

Of course the XML document is a lot more complex and the receiving DS has to account for that. I've written many articles on the topic of XML-INTO - shout if you have any trouble finding them.

[LBurkett99]

Will xml_into function correctly when the sequence of elements in the data structure is not same as the sequence in the XML?

[JonBoy]

Will xml_into function correctly when the sequence of elements in the data structure is not same as the sequence in the XML?

Yes - as I said earlier "If you were to use RPG's XML-INTO it would take care of this automagically ...". As long as they are at the same level of the hierarchy (which they will be) XML-INTO doesn't care about the sequence. In XML terms, if the schema does not specify a sequence then items at a given level can be in any sequence and XML-INTO accommodates that.

[LBurkett99]

Thank you. This answers my original question. The sequence of elements can differ and the document still be valid.

The program I am working with processes some element's content before all elements have been extracted. With xml-itnto, this would not happen.

[JonBoy]

Thank you. This answers my original question. The sequence of elements can differ and the document still be valid.

Actually "valid" is the wrong word here. Sorry to be pedantic but with XML there are two levels of "correctness". First an XML document must be "well formed" - that is it obeys the rules of XML. An opening tag has a closing tag, and the names must match (including case), etc. etc. Second level of "correctness" is referred to as "valid" - which is why I picked you up on the use of the word. "Valid" in XML terms means that the document conforms to the schema associated with it. The schema can be a DTD or an XML schema and lays out rules such as - an <Address> must contain one and one only <City> element and must contain a <ZipCode> and may optionally contain a <ZipPlus>. It is the schema that says whether the sequence of elements within a level is significant. An XML document can be well formed but not valid. If it is valid it must be well formed.

Hope this helps clarify.

[LBurkett99]

Thank you.