[
https://issues.apache.org/jira/browse/DAFFODIL-2738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17616497#comment-17616497
]
Steve Lawrence commented on DAFFODIL-2738:
------------------------------------------
Here is smaller schema that reproduces the issue:
{code:xml}
<schema
xmlns="http://www.w3.org/2001/XMLSchema";
xmlns:xs="http://www.w3.org/2001/XMLSchema";
xmlns:dfdl="http://www.ogf.org/dfdl/dfdl-1.0/";
xmlns:dfdlx="http://www.ogf.org/dfdl/dfdl-1.0/extensions";
xmlns:tns="example.com"
targetNamespace="example.com">
<include schemaLocation="org/apache/daffodil/xsd/DFDLGeneralFormat.dfdl.xsd"
/>
<annotation>
<appinfo source="http://www.ogf.org/dfdl/";>
<dfdl:format
ref="tns:GeneralFormat"
representation="binary"
/>
</appinfo>
</annotation>
<element name="root" type="tns:level1" />
<simpleType name="level1">
<restriction base="tns:level2"/>
</simpleType>
<simpleType name="level2" dfdlx:repType="tns:rep" dfdl:length="1">
<restriction base="tns:myString">
<enumeration value="ONE" dfdlx:repValues="1"/>
<enumeration value="TWO" dfdlx:repValues="2"/>
<enumeration value="TRE" dfdlx:repValues="3"/>
</restriction>
</simpleType>
<simpleType name="myString" dfdl:lengthKind="explicit">
<restriction base="xs:string"/>
</simpleType>
<simpleType name="rep" dfdl:length="1">
<restriction base="tns:myLong"/>
</simpleType>
<simpleType name="myLong" dfdl:lengthKind="explicit">
<restriction base="xs:unsignedLong"/>
</simpleType>
</schema>
{code}
The core issue is that there is an extra level of indirection to get to the
dfdlx:repType property from the root element. The way the repType property
works is it must be defined directly on the element or on the direct
simpleType. Because this case the repType is not in one of these places, the
property is essentially ignored and the root element is just parsed as the
primitive type, which is an xs:string.
So, this is currently behaving as expected. Removing the extra level of
indirection and making root have type tns:level2 allows it to parse as expected.
Is possible to remove the level of indirection in your schema? If so, I'd like
to close this as working as expected.
We may want to consider a future enhancement to allow the property to be on any
simple type or child one, but there are potential complications that need to be
thought through before supporting that. If you can work around this by removing
the indirection, that would be a better short term solution.
> dfdlx:repType's incorrect handling of Binary Long to String enumerations
> ------------------------------------------------------------------------
>
> Key: DAFFODIL-2738
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2738
> Project: Daffodil
> Issue Type: Bug
> Components: Back End
> Affects Versions: 3.3.0
> Reporter: Olabusayo Kilo
> Assignee: Steve Lawrence
> Priority: Major
> Fix For: 3.4.0
>
>
> This is part of a large schema project. So link access to the schema project
> will follow in a different comment.
> But a short synopsis is when the repType of an element in a binary data
> format is an unsignedlong, the repType is ignored in favor of treating the
> element like a string type.
> For example:
> {code:xml}
>
> <xs:element name="a" type="tns:jobEnum"/>
> <simpleType name="jobEnum" dfdlx:repType="xs:enum4">
> <restriction base="xs:string">
> <enumeration value="CTO" dfdlx:repValues="1"/>
> <enumeration value="MANAGER" dfdlx:repValues="2"/>
> <enumeration value="TEAM_LEAD" dfdlx:repValues="3"/>
> </restriction>
> </simpleType>
> <xs:simpleType name="enum4" dfdl:length="4" dfdl:lengthKind="explicit"
> dfld:lengthUnit="bits">
> <xs:restriction base="xs:unsignedLong"/>
> </xs:simpleType>
> {code}
>
> Would result in the following trace
> {code:xml}
> <Element name='a'><SpecifiedLengthExplicitParser><a
> parser='StringOfSpecifiedLengthParser'
> /></SpecifiedLengthExplicitParser><AssertExpressionEvaluationParser/></Element>
> {code}
> rather than
> {code:xml}
> <Element name='a'><SpecifiedLengthExplicitParser><a
> parser='Binary*SpecifiedLengthParser'
> /></SpecifiedLengthExplicitParser><AssertExpressionEvaluationParser/></Element>
> {code}
> Unfortunately the workaround mentioned in
> https://issues.apache.org/jira/browse/DAFFODIL-2596?focusedCommentId=17475017&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17475017,
> won't work for our usecase because the data is binary and has very specific
> bit length requirements.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
