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.)

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