[DFDL-WG] Fw: Thoughts on a discriminator scenario
Steve Hanson
smh at uk.ibm.com
Mon Jan 27 12:41:05 EST 2014
Been thinking some more on the discriminator scenario below that I mailed
out before xmas, and discussing it with the IBM DFDL team.
The 'confusing' aspect of the behaviour is that a discriminator within a
potential PoU will act on a higher level PoU if the potential PoU is not
an actual PoU. In the example, the array element 'Type1' is not an actual
PoU for occurrence 1, only for occurrences 2+. So when the discriminator
fires for occurrence 1 it will resolve a higher level unresolved PoU if
one exists.
Perhaps the spec should say that a discriminator can't 'leak' beyond the
potential PoU that encloses it ? If so, then for occurrence 1 the
discriminator has no effect, and only has an effect for occurrences 2+.
This makes for more predictable and robust schemas.
We'd need to go through spec section 9.3.3 carefully to see if this does
not break any of the potential PoUs that are listed.
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
----- Forwarded by Steve Hanson/UK/IBM on 16/01/2014 09:55 -----
From: Steve Hanson/UK/IBM
To: dfdl-wg at ogf.org,
Date: 20/12/2013 13:20
Subject: Thoughts on a discriminator scenario
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
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/20140127/2db41deb/attachment.html>
More information about the dfdl-wg
mailing list