[
https://issues.apache.org/jira/browse/DAFFODIL-2875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17898425#comment-17898425
]
Robert Bathmann commented on DAFFODIL-2875:
-------------------------------------------
This schema example also produces an incorrect warning message about ignoring
the dfdl:choiceDispatchKey in this case. This seems to be caused by the two
references to the same group containing this property.
{code:xml}
<xs:schema
xmlns:dfdl="http://www.ogf.org/dfdl/dfdl-1.0/";
xmlns:xs="http://www.w3.org/2001/XMLSchema";>
<xs:include
schemaLocation="/org/apache/daffodil/xsd/DFDLGeneralFormat.dfdl.xsd" />
<xs:annotation>
<xs:appinfo source="http://www.ogf.org/dfdl/";>
<dfdl:format ref="GeneralFormat" lengthKind="delimited" />
</xs:appinfo>
</xs:annotation>
<xs:element name="myTestRoot">
<xs:complexType>
<xs:sequence>
<xs:element name="keyValue" type="xs:string" dfdl:length="1"
dfdl:lengthKind="explicit" />
<xs:group ref="groupWithChoice" />
<xs:group ref="groupWithChoice" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:group name="groupWithChoice">
<xs:choice dfdl:choiceDispatchKey="{keyValue}">
<xs:element name="ifA" dfdl:choiceBranchKey="A" type="xs:string"
dfdl:length="1" dfdl:lengthKind="explicit" />
<xs:element name="ifB" dfdl:choiceBranchKey="B" type="xs:string"
dfdl:length="1" dfdl:lengthKind="explicit" />
</xs:choice>
</xs:group>
</xs:schema>
{code}
A suitable workaround to avoid the warning seems to be wrapping the group:
{code:xml}
<xs:group name="groupWrapper">
<xs:sequence>
<xs:group ref="groupWithChoice" />
</xs:sequence>
</xs:group>
{code}
And only referencing the wrapper in the sequence where it appears more than
once:
{code:xml}
...
<xs:group ref="groupWrapper" />
<xs:group ref="groupWrapper" />
...
{code}
While this is a simplified example, this problem also occurs if the referenced
groups are nested at any level under a common element, even among different
types. It can then be less obvious that this repetition causes the erroneous
warning.
> Incorrect warning about ignored properties
> ------------------------------------------
>
> Key: DAFFODIL-2875
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2875
> Project: Daffodil
> Issue Type: Bug
> Components: Front End
> Reporter: Steve Lawrence
> Assignee: Olabusayo Kilo
> Priority: Major
>
> Say we have this schema:
> {code:xml}
> <xs:schema
> xmlns:dfdl="http://www.ogf.org/dfdl/dfdl-1.0/";
> xmlns:xs="http://www.w3.org/2001/XMLSchema";>
>
> <xs:include
> schemaLocation="/org/apache/daffodil/xsd/DFDLGeneralFormat.dfdl.xsd" />
>
> <xs:annotation>
> <xs:appinfo source="http://www.ogf.org/dfdl/";>
> <dfdl:format ref="GeneralFormat" lengthKind="delimited" />
> </xs:appinfo>
> </xs:annotation>
>
> <xs:element name="DinnerTime">
> <xs:complexType>
> <xs:choice>
> <xs:element ref="MonthDayTime" />
> <xs:element ref="DayTime" />
> </xs:choice>
> </xs:complexType>
> </xs:element>
>
> <xs:element name="MonthDayTime">
> <xs:complexType>
> <xs:sequence>
> <xs:element ref="Month"/>
> <xs:element ref="Day"/>
> </xs:sequence>
> </xs:complexType>
> </xs:element>
>
> <xs:element name="DayTime">
> <xs:complexType>
> <xs:sequence>
> <xs:element ref="Day"/>
> </xs:sequence>
> </xs:complexType>
> </xs:element>
>
> <xs:element name="Month"
> type="xs:unsignedInt"
> dfdl:lengthKind="explicit"
> dfdl:length="2"
> dfdl:textNumberRep="standard"
> dfdl:textNumberCheckPolicy="strict"
> dfdl:textNumberPattern="00"
> dfdl:textStandardGroupingSeparator=","
> dfdl:textStandardDecimalSeparator="."
> dfdl:textStandardBase="10"
> dfdl:textNumberRounding="pattern">
> </xs:element>
>
> <xs:element name="Day"
> type="xs:unsignedInt"
> dfdl:lengthKind="explicit"
> dfdl:length="2"
> dfdl:textNumberRep="standard"
> dfdl:textNumberCheckPolicy="strict"
> dfdl:textNumberPattern="00"
> dfdl:textStandardGroupingSeparator=","
> dfdl:textStandardDecimalSeparator="."
> dfdl:textStandardBase="10"
> dfdl:textNumberRounding="pattern">
> </xs:element>
>
> </xs:schema>
> {code}
> When compiling this schema we get the warnings:
> {quote}
> [warn] Schema Definition Warning: DFDL property was ignored:
> textStandardBase="10" (id: ignoreDFDLProperty)
> Schema context: Day Location line 52 column 4 in
> .../home/slawrence/downloads/foo.dfdl.xsd
> [warn] Schema Definition Warning: DFDL property was ignored:
> textNumberPattern="00" (id: ignoreDFDLProperty)
> Schema context: Day Location line 52 column 4 in
> .../home/slawrence/downloads/foo.dfdl.xsd
> [warn] Schema Definition Warning: DFDL property was ignored:
> textNumberRounding="pattern" (id: ignoreDFDLProperty)
> Schema context: Day Location line 52 column 4 in
> .../home/slawrence/downloads/foo.dfdl.xsd
> [warn] Schema Definition Warning: DFDL property was ignored:
> textNumberRep="standard" (id: ignoreDFDLProperty)
> Schema context: Day Location line 52 column 4 in
> .../home/slawrence/downloads/foo.dfdl.xsd
> [warn] Schema Definition Warning: DFDL property was ignored:
> textNumberCheckPolicy="strict" (id: ignoreDFDLProperty)
> Schema context: Day Location line 52 column 4 in
> .../home/slawrence/downloads/foo.dfdl.xsd
> {quote}
> Testing shows this warnings are clearly wrong and are not actually ignored.
> One workaround is to use a separate simpleType for your elements and use that
> as the type of your referenced element. For example, change your Day element
> to this:
> {code:xml}
> <xs:element name="Day" type="DayType" />
> <xs:simpleType name="DayType"
> ... DFDL properties here ... >
> <xs:restriction base="xs:unsignedInt />
> </xs:simpleType>
> {code}
> You can reference Day just like you did before, e.g.
> {code:xml}
> <xs:element ref="Day" />
> {code}
> For reference, here's what I think is going on:
> The schema has multiple references to the same elements (e.g. two references
> to the Day element). This allows Daffodil to share internal parsers. So even
> though there are two references to the "Day" element, we only generate one
> "Day" sub-parser, and reuse the exact same sub-parser in two different places
> in the final parser we generate. This can pretty drastically reduce schema
> compilation time because we can completely skip building a second sub-parser
> that is identical.
> The problem is that we store which properties an element uses on the local
> element that does the referencing, not the element that is actually
> referenced. So we have two different lists of "used properties".
> The first local element generates a sub-parser for the referenced element,
> and that uses all of the properties, and marks the properties as used by the
> first local element.
> The second local element figures out that it can share the sub-parser, so any
> properties that are used when that sub-parser is generated do not get marked
> as used on the second local element.
> And then when we do our check for unused properties, from the perspective of
> the second local element, some properties were never used because it doesn't
> know the first local element used them and the second element skipped all
> that work.
> And I think the workaround works because the referenced element has no
> properties defined directly on it so it looks like there are no properties
> that might be unused. This might actually be a related bug, in that we should
> be considering if the properties defined on the simple type of the referenced
> element are used or not. With the mentioned workaround, I've confirmed that
> if the simple type has properties that are not used then there is no warning
> like there should be.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
