Take the following schema (simplified)
for element Type1 (1,10) being a loop for elements A,B,C. Type 1
does not have an initiator so I need to use a discriminator to establish
the existence of an occurrence of Type1 so that incorrect backtracking
does not occur after an error. Because occursCountKind is 'implicit', the
1st occurrence is not a point of uncertainty so the discriminator
acts instead on any enclosing point of uncertainty, but for 2nd and subsequent
occurrences it acts on Type1. That is all working as designed, but
I think users will the 1st occurrence behaviour a bit confusing. There
are workarounds to avoid the problem, eg, use occursCountKind 'parsed'
or split Type1 into two as (1,1) and (0,9). I think this is worth documenting
in a tutorial as this is quite subtle stuff.
<xs:element
name="Type1" maxOccurs="10" dfdl:occursCountKind="implicit">
<dfdl:discriminator
test="{fn:exists(A)}" />
<xs:complexType>
<xs:sequence>
<xs:element name="A" dfdl:initiator="A:"
... />
<xs:element
name="B" dfdl:initiator="B:" ... />
<xs:element
name="C" dfdl:initiator="C:"... />
</xs:sequence>
</xs:complexType>
Regards
Steve Hanson
Architect, IBM Data Format Description Language (DFDL)
Co-Chair, OGF
DFDL Working Group
IBM SWG, Hursley, UK
smh@uk.ibm.com
tel:+44-1962-815848
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU