[DFDL-WG] Fw: UnorderedInitiated

Tue May 5 07:56:53 CDT 2009

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. 

  _____  

From: dfdl-wg-bounces at ogf.org [mailto:dfdl-wg-bounces at ogf.org] On Behalf Of
Steve Hanson
Sent: Wednesday, April 29, 2009 5:57 AM
To: dfdl-wg at ogf.org
Subject: [DFDL-WG] Fw: UnorderedInitiated

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 at 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 at IBMGB 

Subject
Re: UnorderedInitiatedLink
<Notes://D06ML070/802563ED00496501/38D46BF5E8F08834852564B500129B2C/666DBFE0
83B2A71380257599007AD5C9> 

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 at uk.ibm.com
Phone (+44)/(0) 1962-815848 

Tim Kimber/UK/IBM 

15/04/2009 23:26 

To
Alan Powell/UK/IBM at IBMGB 

cc
Steve Hanson/UK/IBM at IBMGB 

Subject
Re: UnorderedInitiatedLink
<Notes://D06ML070/802563ED00496501/38D46BF5E8F08834852564B500129B2C/064D1583
9B78BE6580257599002F520D> 

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 at uk.ibm.com
Tel. 01962-816742  
Internal tel. 246742

From: 	Alan Powell/UK/IBM 

To: 	Tim Kimber/UK/IBM at IBMGB 

Cc: 	Steve Hanson/UK/IBM at 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 at uk.ibm.com  
Tel: +44 (0)1962 815073                  Fax: +44 (0)1962 816898

From: 	Tim Kimber/UK/IBM 

To: 	Alan Powell/UK/IBM at IBMGB 

Cc: 	Steve Hanson/UK/IBM at IBMGB, Dragan Besevic/Boca Raton/IBM at IBMUS,
Sunil Dandamudi/Boca Raton/IBM at IBMUS, Lorenzito Jimenez/Boca Raton/IBM at 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 at uk.ibm.com
Tel. 01962-816742  
Internal tel. 246742

From: 	Alan Powell/UK/IBM 

To: 	Tim Kimber/UK/IBM at IBMGB 

Cc: 	Steve Hanson/UK/IBM at 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 at uk.ibm.com  
Tel: +44 (0)1962 815073                  Fax: +44 (0)1962 816898

From: 	Tim Kimber/UK/IBM 

To: 	Steve Hanson/UK/IBM at IBMGB, Alan Powell/UK/IBM at 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 at 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 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/dfdl-wg/attachments/20090505/7c47046c/attachment.html 