Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
Description
Say we have this schema:
<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>
When compiling this schema we get the warnings:
[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
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:
<xs:element name="Day" type="DayType" /> <xs:simpleType name="DayType" ... DFDL properties here ... > <xs:restriction base="xs:unsignedInt /> </xs:simpleType>
You can reference Day just like you did before, e.g.
<xs:element ref="Day" />
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.