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@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: UnorderedInitiated 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: UnorderedInitiated 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
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 | <mailto:mbeckerle.dfdl@gmail.com> mbeckerle.dfdl@gmail.com _____ From: dfdl-wg-bounces@ogf.org [mailto:dfdl-wg-bounces@ogf.org] On Behalf Of Steve Hanson Sent: Wednesday, April 29, 2009 5:57 AM To: dfdl-wg@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@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 <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@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 <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@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
participants (2)
-
Mike Beckerle -
Steve Hanson