[DFDL-WG] Direct dispatch choice clarifications

[Steve Hanson]

Looking at this in more detail prior to writing up behaviour for section 
9, there are a couple of things missing from the spec or that need 
clarification:

1) Description of elementID property should say that empty string is not 
allowed (this was in the erratum).

2) Should say that an elementID on an elementRef overrides any elementID 
on the global element (this was in the erratum). 

3) Section 15.1.2 says that is a schema definition error if the elementId 
values of global elements are not unique within a given namespace. I don't 
see where namespace comes into this, the elementID is just a string so 
surely it needs to be unique across namespaces? (Strictly elementID needs 
only to be unique across the global elements involved in each specific 
choice, but it was minuted that global uniqueness was desirable to allow 
future xs:any support).

4) Spec does not explicitly say that when choiceBranchRef is present each 
branch of the choice must have an elementID. This must be the case, as 
otherwise a choice branch will never be accessible. 

5) Tim has suggested that if an element was silent about elementID, the 
local name of the element could be used instead. So conceptually an 
element would have an 'effective elementID'.  This makes modelling easier 
if the 'tag' in the data is the same as the element name. The validation 
checks would need to ensure that the set of 'effective elementIDs' was 
unique; for the global element check as currently specified (see 3) this 
would mean that all global elements must have unique local names, unless 
an elementID is carried - I think this is too limiting. 


>From minutes of 17th April 2012.

145
Provide a 'dispatch' way of discriminating a choice for better performance 
of the envelope/payload use case (Steve, Mike, Suman)
12/7: See minutes. Need to choose a proposal and flesh out.
19/07:  Waiting for proposals
26/07:  Waiting for proposals
16/08: Waiting for proposals. Suman added to action.
...
1/11:  Steve to send a proposal
...
21/03: Steve has sent a proposal. Mike has sent a counter proposal. Steve 
to respond.
28/03: Steve has sent a revised proposal.  Review for discussion next 
week. Ensure proposal handles Mike's scenario where tag value to branch 
mapping is not 1-1.
05/04: Discussed Mike's review comments and Suman's concerns. Agreed that 
name should be elementID, should be a single DFDL String Literal value, 
and that matching of choiceBranchRef expression result should only be 
against elementID to avoid QName v String confusion. Steve to recirculate 
with a schema example.
17/04: Closed. Discussion on whether the choiceBranchRef expression should 
retiurn xs:string or something else. Agreed on xs:string. Discussed 
whether elemenID should be a pure xs:string or a DFDL String Literal. For 
consistency with other DFDL properties it should be a string literal, but 
raw byte entities and character classes should be disallowed to avoid 
complications. Discussed scope of uniqueness of elementIDs. Agreed that 
uniqueness is both local to a choice, and across all global elements in 
the same namespace (the latter is not strictly needed right now but 
accommodates any future addition of xs:any). Agreed that elementID should 
be on global element, local element, and element ref (in which case it 
overrides any elementId on the global element, which is ok as the property 
does not follow the usual scoping rules). Errata taken.

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/20130815/1d935c3f/attachment.html>