I am a bit confused with the behaviour of one of my test cases. I have the
schema:
<xs:simpleType name="AbstractMulitiply2FromInt" dfdl:repType="xs:int"
dfdl:outputTypeCalc="{ dfdl:logicalTypeValueInt() * 2 }">
<xs:restriction base="xs:int"/>
</xs:simpleType>
<xs:element name="outputTypeCalcNextSiblingInt_01">
<xs:complexType>
<xs:sequence>
<xs:element name="raw" type="tns:uint8" dfdl:outputValueCalc="{
dfdl:outputTypeCalcNextSiblingInt() }"/>
<xs:element name="logic" type="tns:AbstractMulitiply2FromInt"
dfdl:length="1" dfdl:inputValueCalc="{ 0 }"/>
</xs:sequence>
</xs:complexType>
</xs:element>
With the test case:
<tdml:unparserTestCase name="outputTypeCalcNextSiblingInt_01"
root="outputTypeCalcNextSiblingInt_01"
model="inputTypeCalc-Embedded.dfdl.xsd" description="Extensions - inputTypeCalc
keysetValue transform">
<tdml:document>
<tdml:documentPart type="byte">
0E
</tdml:documentPart>
</tdml:document>
<tdml:infoset>
<tdml:dfdlInfoset xmlns:xs="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
<outputTypeCalcNextSiblingInt_01>
<logic>7</logic>
</outputTypeCalcNextSiblingInt_01>
</tdml:dfdlInfoset>
</tdml:infoset>
</tdml:unparserTestCase>
As I understand it, this should result in an error since the infoset is missing
the requires <raw> element and is thus not xsd-valid with the schema (this was
an oversight in my writing the test, and if that is what I was seeing I would
simply fix it and move on).
However, that is not what I am observing, instead the unparser is attempting to
unparse it. The trace functionality reveals that it is constructing the infoset:
<ex:outputTypeCalcNextSiblingInt_01 xmlns:ex="http://example.com";>
<ex:logic>7</ex:logic>
<ex:raw></ex:raw>
</ex:outputTypeCalcNextSiblingInt_01>
This is almost what I would expect if <raw> where a hidden element. However,
note that the ordering of <logic><raw> does not match the ordering <raw><logic>
defined by schema.
I have confirmed in the debugger that the contents array of
outputTypeCalcNextSiblingInt_01 has <logic> as the first element and <raw> as
the second.
Apart from my not understanding how the above infoset is being accepted in the
first place, the actual issue I am running into is the ordering in the internal
infoset; as the implementation of dfdl:outputTypeCalcNextSiblingInt requires
that the ordering information be preserved.
Thoughts?
Brandon T. Sloane
Associate, Services
[email protected] | tresys.com
