I'm not sure how the OVC element could appear after where it is supposed
to appear, but we do actually allow OVC elements to be missing from the
infoset. Whether or not this is correct might be up for debate.
The logic for creating OVC elements that are missing is in the
OVCStartEndStrategy trait in ElementUnparser.scala. I'd guess there is a
logic bug in there that's causing things to get added out of order.
Nothing obvious is jumping out at me though.
- Steve
On 4/10/19 12:45 PM, Sloane, Brandon wrote:
> 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
>
