See comment in <TK> tags.
regards,
Tim Kimber, DFDL Team,
Hursley, UK
Internet: kimbert@uk.ibm.com
Tel. 01962-816742
Internal tel. 37246742
From:
Steve Hanson/UK/IBM@IBMGB
To:
dfdl-wg@ogf.org,
Date:
15/08/2013 12:57
Subject:
[DFDL-WG] Direct
dispatch choice clarifications
Sent by:
dfdl-wg-bounces@ogf.org
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).
<TK>
In XML Schema, an xs:any
does not, in general, match all global elements. The 'namespace' attribute
can narrow the set to elements from a specified list of namespaces. There
is no way in XML Schema 1.0 to further narrow the xs:any, So the
rule is designed to ensure that future usage of xs:any when a single
namespace is specified and processContents!='skip' does not throw up
schema definition errors. However...I note that XML Schema 1.1 allows a
new way to narrow the scope of an xs:any ( by specifying a list of not-included
QNames ). My feeling is that the unique-within-namespace check is fragile.
</TK>
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.
<TK>...or if the element
name is derivable from the 'tag' using a simple XPath expression</TK>
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@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--
dfdl-wg mailing list
dfdl-wg@ogf.org
https://www.ogf.org/mailman/listinfo/dfdl-wg
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