[DFDL-WG] Thoughts on a discriminator scenario

[Steve Hanson]

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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20131220/ec6dc1cb/attachment.html>