-
Bug
-
Resolution: Unresolved
-
Normal
-
None
-
None
(Bug found in Link16 work. Reproduced in tests test_choiceSlotAmbiguous1 and test_choiceSlotAmbiguous2)
Consider this choice:
|
|
<xs:choice>
|
<xs:sequence>
|
<xs:element name="A" type="xs:string" dfdl:length="1" /> |
<xs:element name="C" type="xs:string" dfdl:length="1"> |
<xs:annotation>
|
<xs:appinfo source="http://www.ogf.org/dfdl"> |
<dfdl:discriminator>{ ../A eq "A" }</dfdl:discriminator> |
</xs:appinfo>
|
</xs:annotation>
|
</xs:element>
|
</xs:sequence>
|
<xs:sequence>
|
<xs:element name="B" type="xs:string" dfdl:length="1" /> |
<xs:element name="C" type="xs:string" dfdl:length="1"> |
<xs:annotation>
|
<xs:appinfo source="http://www.ogf.org/dfdl"> |
<dfdl:discriminator>{ ../B eq "B" }</dfdl:discriminator> |
</xs:appinfo>
|
</xs:annotation>
|
</xs:element>
|
</xs:sequence>
|
</xs:choice>
|
Now imagine a subsequent expression containing ../C.
Which C is that? The first or second. Answer is it depends on which discriminator was chosen.
If the first discriminator is true, then the path ../C succeeds. If the second discriminator was true the path ../C fails with no such element C.
This is probably due to Daffodil's schema compiler assigning two different slot numbers to these two C elements, rather than recognizing they have the same name+namespace and so using a single slot for them.
