I believe this piece of redundancy is helpful regardless of
what we call it.
In the unordered case it expresses that
you intend the enclosed constructs to be disambiguated by way of initiators, and
if there's any ambiguity then that must be a schema definition error. It allows
the processor to grab the immediate children of the sequence, ask for their
initiators, and check that they are not ambiguous based on that information
alone.
With regard to the children of sequences being restricted
to elements only: I continue to be in favor of conservative choices that
we can free-up later if we find a need to, without introducing backward
incompatibility. So I would say generally children of sequences should only be
elements; however, I believe we are allowing model group children of sequences
so long as things aren't ambiguous. For unordered sequences, I think we should
require them to be elements only.
Part of the rationale driving my decisions here is to make
it possible to create somewhat unsophisticated DFDL parsers which can still give
reasonable diagnostic messages without having to have complex "compiler-like"
schema analyzers.
Mike Beckerle |
OGF DFDL WG Co-Chair | CTO | Oco, Inc.
Tel:
781-810-2125 | 100 Fifth
Ave., 4th Floor, Waltham MA 02451 | mbeckerle.dfdl@gmail.com
It has been raised that the
dfdl:unorderedInitiated property is redundant, because we have speculative
parsing, and because the DFDL parser can optimise by analysis without being
explicitly told. This is true but saying that all children of a sequence
have an initiator is also a way for the modeler to ensure that his model is
correct and that all children are correctly specified. I propose that we
decide whether to:
a) Drop the
property
b) Rename the property
dfdl:initiated and have it apply to any sequence, ordered or unordered
There's also a question in the spec that we
should resolve.
(TBD: do we allow
sequences with initiators to be children of an unordered sequence, or do we
require the children of an unordered sequence to be elements? Conservative would
be to require elements.)
To which Mike had commented:
Suggest sequences where children have
initiators cannot be directly nested. You must use an element in this case. I
would prefer that children of an unordered sequence are required to be elements
in general for v1.0.
I'd like to close on this as well.
Let's discuss on today's
call.
Regards
Steve
Hanson
Programming Model Architect
WebSphere Message Brokers
Hursley,
UK
Internet: smh@uk.ibm.com
Phone (+44)/(0) 1962-815848
----- Forwarded by Steve Hanson/UK/IBM on
29/04/2009 10:38 -----
| Steve
Hanson/UK/IBM
28/04/2009 15:41
|
|
To
| Tim Kimber/UK/IBM
|
|
cc
| Alan Powell/UK/IBM@IBMGB
|
|
Subject
| Re: UnorderedInitiatedLink |
|
Here's the table from draft 0.33:
|
sequenceKind
|
separatorPolicy
|
Implications |
| unorderedInitiated
| ignored (suppress behavior implied)
| Initiators are used to identify
which elements are present and which are missing.
All children must have dfdl:initiator strings
that are distinct and not the empty string. (Schema definition error
otherwise.)
nilValueInitiatorPolicy and
defaultValueInitiatorPolicy must both be 'required' (Schema definition
error otherwise) |
Setting unorderedInitiated forces extra checks to take place to ensure
that an initiator would be present under all circumstances. I think this
provides a direct equivalent to TDS Tagged.
I'd prefer that speculative parsing was the sole mechanism used to
resolve the child elements. In practice, most unordered sequences will have
initiators on their children anyway.
There's also this comment in the spec:
(TBD: do we allow sequences with initiators to be children of an
unordered sequence, or do we require the children of an unordered sequence to be
elements? Conservative would be to require elements.)
To which Mike had commented:
Suggest sequences where children have
initiators cannot be directly nested. You must use an element in this case. I
would prefer that children of an unordered sequence are required to be elements
in general for v1.0.
Which corresponds to schema's rule for xs:all
and the MRM's rule for unorderedSet, so I'm happy with that.
Regards
Steve Hanson
Programming Model Architect
WebSphere
Message Brokers
Hursley, UK
Internet: smh@uk.ibm.com
Phone (+44)/(0)
1962-815848
| Tim
Kimber/UK/IBM
15/04/2009 23:26
|
|
To
| Alan Powell/UK/IBM@IBMGB
|
|
cc
| Steve Hanson/UK/IBM@IBMGB
|
|
Subject
| Re: UnorderedInitiatedLink |
|
Hi Alan,
Understood. In that
case, please can you add this to the list of unresolved issues in the
specification. We should take pains not to include redundant properties in DFDL
v1.0, because each property has a cost in terms of implementation, testing and
documentation.
regards,
Tim
Kimber, Common Transformation Team,
Hursley, UK
Internet:
kimbert@uk.ibm.com
Tel. 01962-816742
Internal tel.
246742
| From:
| Alan Powell/UK/IBM
|
| To:
| Tim Kimber/UK/IBM@IBMGB
|
| Cc:
| Steve Hanson/UK/IBM@IBMGB
|
| Date:
| 15/04/2009 09:37
|
| Subject:
| Re:
UnorderedInitiated |
Tim
The problem with committees is that you can't just decide by yourself to
drop something.
Alan
Powell
MP 211, IBM UK Labs, Hursley, Winchester, SO21 2JN,
England
Notes Id: Alan Powell/UK/IBM email:
alan_powell@uk.ibm.com
Tel: +44 (0)1962 815073
Fax: +44 (0)1962
816898
| From:
| Tim Kimber/UK/IBM
|
| To:
| Alan Powell/UK/IBM@IBMGB
|
| Cc:
| Steve Hanson/UK/IBM@IBMGB, Dragan
Besevic/Boca Raton/IBM@IBMUS, Sunil Dandamudi/Boca Raton/IBM@IBMUS,
Lorenzito Jimenez/Boca Raton/IBM@IBMUS
|
| Date:
| 14/04/2009 21:19
|
| Subject:
| Re:
UnorderedInitiated |
Alan,
Thanks for the clarification. If that is the only reason for the property
then it should be removed in v0.34. The PIF generator can easily perform that
kind of optimisation ( if necessary ). This is not the only optimisation
which the PIF generator might want to perform, and the specification does not
supply extra properties for those other cases.
regards,
Tim Kimber, Common Transformation
Team,
Hursley, UK
Internet: kimbert@uk.ibm.com
Tel. 01962-816742
Internal tel. 246742
| From:
| Alan Powell/UK/IBM
|
| To:
| Tim Kimber/UK/IBM@IBMGB
|
| Cc:
| Steve Hanson/UK/IBM@IBMGB
|
| Date:
| 14/04/2009 17:23
|
| Subject:
| Re:
UnorderedInitiated |
Tim
There is a history.
You are
correct that speculative parsing should take care of it all. However originally
unordered elements had to be initiated. When that was relaxed it was felt that
it was worth giving the parser a chance to optimize to initiated case. Designed
by committee.
Alan Powell
MP
211, IBM UK Labs, Hursley, Winchester, SO21 2JN, England
Notes Id: Alan
Powell/UK/IBM email: alan_powell@uk.ibm.com
Tel: +44
(0)1962 815073
Fax: +44 (0)1962 816898
| From:
| Tim Kimber/UK/IBM
|
| To:
| Steve Hanson/UK/IBM@IBMGB, Alan
Powell/UK/IBM@IBMGB
|
| Date:
| 08/04/2009 22:54
|
| Subject:
| UnorderedInitiated |
I can't see why this is required, but I'm
probably missing something. Wouldn't the normal speculative parsing rules will
make use of the initiator if it is present. Or does unorderedInitiated cause the
initiator to behave as a discriminator? If so, I would prefer to leave that to
the user. We don't do it for any other point of uncertainty ( there's no
equivalent choiceInitiated setting ).
regards,
Tim Kimber, Common Transformation Team,
Hursley,
UK
Internet: kimbert@uk.ibm.com
Tel. 01962-816742
Internal
tel. 246742
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