The XML Schema specification permits an element or attribute to contain a list of values based on a simple type with the individual values separated by white space.
<message1> <listE1 listAttr="one two three"> four five six</listE1> </message1>
In the resulting message tree, an xsd::list type is represented as a name node with an anonymous value child for each list item. This allows repeating lists to be handled without any loss of information.
MRM listEl (Name) listAttr (Name) "one" (Value) "two" (Value) "three" (Value) "four" (Value) "five" (Value) "six" (Value)
SET OutputRoot.MRM.listEl.listAttr.*[3] = ...modifies the third item of listAttr.
<MRM> <inner>abcde fghij 12345</inner> </MRM>where the element inner is of type xsd::list, so it has three associated string values, rather than a single value.
<MRM> <str1>abcde</str1> <str1>fghij</str1> <str1>12345</str1> </MRM>it is reasonable to assume that the following ESQL syntax works:
DECLARE D INTEGER; SET D = CARDINALITY(InputBody.str1.*[]); DECLARE M INTEGER 1; WHILE M <= D DO SET OutputRoot.MRM.str1[M] = InputBody.inner.*[M]; SET M = M + 1; END WHILE;
SET OutputRoot.MRM.str1[M] = InputBody.inner.*[M];requests a tree copy from source to target. Since the target element does not yet exist, it is created and its value and type are set from the source.
This is consistent with ESQL's behavior elsewhere, but in the case of elements having values of type list, this code can produce spurious validation errors.
SET OutputRoot.MRM.str1[M] = FIELDVALUE(InputBody.inner.*[M]);
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
ak05141_ |