Fwd: [dfdl] initiatedContent w/o initiators
Forgot to copy the workgroup. ---------- Forwarded message ---------- From: Mike Beckerle <mbeckerle.dfdl@gmail.com> Date: Fri, May 31, 2013 at 1:32 AM Subject: Re: [DFDL-WG] [dfdl] initiatedContent w/o initiators To: "Garriss Jr., James P." <jgarriss@mitre.org> You need two nested choices. Only the inner one uses initiated content. <xsd:choice> <xsd:choice dfdl:initiatedContent="yes"> <xsd:element ref="Date"/> <xsd:element ref="From"/> <xsd:element ref="MessageId"/> <xsd:element ref="Subject"/> </xsd:choice> <!-- all unknown and unwanted headers --> <xsd:sequence dfdl:hiddenGroupRef="UnwantedHeadersGroup"/> </xsd:choice> On Thu, May 30, 2013 at 2:49 PM, Garriss Jr., James P. <jgarriss@mitre.org>wrote:
Spec says:****
** **
It is a schema definition error if any children have their dfdl:initiator property set to the empty string.****
** **
Does that include a sequence with a hiddenGroupRef?****
** **
For example, part of a schema for email headers is this:****
** **
<xsd:choice dfdl:initiatedContent="yes">****
<xsd:element ref="Date"/>****
<xsd:element ref="From"/>****
<xsd:element ref="MessageId"/>****
<xsd:element ref="Subject"/>****
<!-- all unknown and unwanted headers -->****
<xsd:sequence dfdl:hiddenGroupRef="UnwantedHeadersGroup"/>****
</xsd:choice>****
** **
Date, From, and the other headers are all elements with initiators, but UnwantedHeadersGroup does not have an initiator (because I don’t know it a priori). ****
** **
Should this throw an error in a DFDL implementation? I suspect it should, though I hope it shouldn’t.****
-- dfdl-wg mailing list dfdl-wg@ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg
-- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com -- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com
I agree with Mike's use of a nested choice, I have used this same pattern to model a catch-all branch on several occasions. I would also add that working out which branch of a choice to take can be an expensive operation for a DFDL parser, and one where optimisations will be applied. The more alike that the branches are, the more likely it will be that the parser can optimise the selection. We still need to answer James' question about schema definition error though. The spec says "When the dfdl:hiddenGroupRef property is specified, all other DFDL properties are ignored." which is saying other properties are not applicable. In other words, such a sequence is present in the schema purely as a device to hide the contents of the group that it refers to. So I think we have a couple of choices when the context in which the sequence appears means that it can not be silent about certain properties: a) The use of dfdl:hiddenGroupRef in that context is a schema definition error. b) Go to the model group content of the hidden group and see whether its properties satisfy the context. 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 From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: dfdl-wg@ogf.org, Date: 31/05/2013 06:37 Subject: [DFDL-WG] Fwd: [dfdl] initiatedContent w/o initiators Sent by: dfdl-wg-bounces@ogf.org Forgot to copy the workgroup. ---------- Forwarded message ---------- From: Mike Beckerle <mbeckerle.dfdl@gmail.com> Date: Fri, May 31, 2013 at 1:32 AM Subject: Re: [DFDL-WG] [dfdl] initiatedContent w/o initiators To: "Garriss Jr., James P." <jgarriss@mitre.org> You need two nested choices. Only the inner one uses initiated content. <xsd:choice> <xsd:choice dfdl:initiatedContent="yes"> <xsd:element ref="Date"/> <xsd:element ref="From"/> <xsd:element ref="MessageId"/> <xsd:element ref="Subject"/> </xsd:choice> <!-- all unknown and unwanted headers --> <xsd:sequence dfdl:hiddenGroupRef="UnwantedHeadersGroup"/> </xsd:choice> On Thu, May 30, 2013 at 2:49 PM, Garriss Jr., James P. <jgarriss@mitre.org
wrote: Spec says:
It is a schema definition error if any children have their dfdl:initiator property set to the empty string. Does that include a sequence with a hiddenGroupRef? For example, part of a schema for email headers is this: <xsd:choice dfdl:initiatedContent="yes"> <xsd:element ref="Date"/> <xsd:element ref="From"/> <xsd:element ref="MessageId"/> <xsd:element ref="Subject"/> <!-- all unknown and unwanted headers --> <xsd:sequence dfdl:hiddenGroupRef="UnwantedHeadersGroup"/> </xsd:choice> Date, From, and the other headers are all elements with initiators, but UnwantedHeadersGroup does not have an initiator (because I don’t know it a priori). Should this throw an error in a DFDL implementation? I suspect it should, though I hope it shouldn’t. -- dfdl-wg mailing list dfdl-wg@ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg -- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com -- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com -- 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
I really prefer (b) below. My rationale: replace the hidden group by a real group reference to the same group. Behavior should not change except for some things show up in the infoset that would have been omitted. That principle should hold anywhere it can, hopefully everywhere. ...mike On Fri, May 31, 2013 at 4:09 AM, Steve Hanson <smh@uk.ibm.com> wrote:
I agree with Mike's use of a nested choice, I have used this same pattern to model a catch-all branch on several occasions.
I would also add that working out which branch of a choice to take can be an expensive operation for a DFDL parser, and one where optimisations will be applied. The more alike that the branches are, the more likely it will be that the parser can optimise the selection.
We still need to answer James' question about schema definition error though. The spec says *"**When the dfdl:hiddenGroupRef property is specified, all other DFDL properties are ignored.**"* which is saying other properties are not applicable. In other words, such a sequence is present in the schema purely as a device to hide the contents of the group that it refers to. So I think we have a couple of choices when the context in which the sequence appears means that it can not be silent about certain properties:
a) The use of dfdl:hiddenGroupRef in that context is a schema definition error.
b) Go to the model group content of the hidden group and see whether its properties satisfy the context.
Regards
Steve Hanson Architect, IBM Data Format Description Language (DFDL) Co-Chair, *OGF DFDL Working Group* <http://www.ogf.org/dfdl/> IBM SWG, Hursley, UK* **smh@uk.ibm.com* <smh@uk.ibm.com> tel:+44-1962-815848
From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: dfdl-wg@ogf.org, Date: 31/05/2013 06:37 Subject: [DFDL-WG] Fwd: [dfdl] initiatedContent w/o initiators Sent by: dfdl-wg-bounces@ogf.org ------------------------------
Forgot to copy the workgroup.
---------- Forwarded message ---------- From: *Mike Beckerle* <*mbeckerle.dfdl@gmail.com*<mbeckerle.dfdl@gmail.com>
Date: Fri, May 31, 2013 at 1:32 AM Subject: Re: [DFDL-WG] [dfdl] initiatedContent w/o initiators To: "Garriss Jr., James P." <*jgarriss@mitre.org* <jgarriss@mitre.org>>
You need two nested choices. Only the inner one uses initiated content.
<xsd:choice> <xsd:choice dfdl:initiatedContent="yes"> <xsd:element ref="Date"/>
<xsd:element ref="From"/>
<xsd:element ref="MessageId"/>
<xsd:element ref="Subject"/>
</xsd:choice>
<!-- all unknown and unwanted headers -->
<xsd:sequence dfdl:hiddenGroupRef="UnwantedHeadersGroup"/>
</xsd:choice>
On Thu, May 30, 2013 at 2:49 PM, Garriss Jr., James P. <* jgarriss@mitre.org* <jgarriss@mitre.org>> wrote: Spec says:
It is a schema definition error if any children have their dfdl:initiator property set to the empty string.
Does that include a sequence with a hiddenGroupRef?
For example, part of a schema for email headers is this:
<xsd:choice dfdl:initiatedContent="yes">
<xsd:element ref="Date"/>
<xsd:element ref="From"/>
<xsd:element ref="MessageId"/>
<xsd:element ref="Subject"/>
<!-- all unknown and unwanted headers -->
<xsd:sequence dfdl:hiddenGroupRef="UnwantedHeadersGroup"/>
</xsd:choice>
Date, From, and the other headers are all elements with initiators, but UnwantedHeadersGroup does not have an initiator (because I don’t know it a priori).
Should this throw an error in a DFDL implementation? I suspect it should, though I hope it shouldn’t.
-- dfdl-wg mailing list *dfdl-wg@ogf.org* <dfdl-wg@ogf.org> *https://www.ogf.org/mailman/listinfo/dfdl-wg*<https://www.ogf.org/mailman/listinfo/dfdl-wg>
-- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | * www.tresys.com* <http://www.tresys.com/>
-- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | * www.tresys.com* <http://www.tresys.com/> -- 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
-- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com
Let's table for discussion on Tuesday's WG call. We also need to walk through the unparser to make sure all the use cases are covered. We've tended to think about dfdl:hiddenGroupRef being used with dfdl:outputValueCalc, but that's not always going to be the case, and there's choices to consider too. I think we should follow the standard defaulting rules for simple and complex elements when unparsing, but we don't say so in the spec. 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 From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: Steve Hanson/UK/IBM@IBMGB, Cc: dfdl-wg@ogf.org Date: 31/05/2013 14:59 Subject: Re: [DFDL-WG] Fwd: [dfdl] initiatedContent w/o initiators I really prefer (b) below. My rationale: replace the hidden group by a real group reference to the same group. Behavior should not change except for some things show up in the infoset that would have been omitted. That principle should hold anywhere it can, hopefully everywhere. ...mike On Fri, May 31, 2013 at 4:09 AM, Steve Hanson <smh@uk.ibm.com> wrote: I agree with Mike's use of a nested choice, I have used this same pattern to model a catch-all branch on several occasions. I would also add that working out which branch of a choice to take can be an expensive operation for a DFDL parser, and one where optimisations will be applied. The more alike that the branches are, the more likely it will be that the parser can optimise the selection. We still need to answer James' question about schema definition error though. The spec says "When the dfdl:hiddenGroupRef property is specified, all other DFDL properties are ignored." which is saying other properties are not applicable. In other words, such a sequence is present in the schema purely as a device to hide the contents of the group that it refers to. So I think we have a couple of choices when the context in which the sequence appears means that it can not be silent about certain properties: a) The use of dfdl:hiddenGroupRef in that context is a schema definition error. b) Go to the model group content of the hidden group and see whether its properties satisfy the context. 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 From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: dfdl-wg@ogf.org, Date: 31/05/2013 06:37 Subject: [DFDL-WG] Fwd: [dfdl] initiatedContent w/o initiators Sent by: dfdl-wg-bounces@ogf.org Forgot to copy the workgroup. ---------- Forwarded message ---------- From: Mike Beckerle <mbeckerle.dfdl@gmail.com> Date: Fri, May 31, 2013 at 1:32 AM Subject: Re: [DFDL-WG] [dfdl] initiatedContent w/o initiators To: "Garriss Jr., James P." <jgarriss@mitre.org> You need two nested choices. Only the inner one uses initiated content. <xsd:choice> <xsd:choice dfdl:initiatedContent="yes"> <xsd:element ref="Date"/> <xsd:element ref="From"/> <xsd:element ref="MessageId"/> <xsd:element ref="Subject"/> </xsd:choice> <!-- all unknown and unwanted headers --> <xsd:sequence dfdl:hiddenGroupRef="UnwantedHeadersGroup"/> </xsd:choice> On Thu, May 30, 2013 at 2:49 PM, Garriss Jr., James P. <jgarriss@mitre.org
wrote: Spec says:
It is a schema definition error if any children have their dfdl:initiator property set to the empty string. Does that include a sequence with a hiddenGroupRef? For example, part of a schema for email headers is this: <xsd:choice dfdl:initiatedContent="yes"> <xsd:element ref="Date"/> <xsd:element ref="From"/> <xsd:element ref="MessageId"/> <xsd:element ref="Subject"/> <!-- all unknown and unwanted headers --> <xsd:sequence dfdl:hiddenGroupRef="UnwantedHeadersGroup"/> </xsd:choice> Date, From, and the other headers are all elements with initiators, but UnwantedHeadersGroup does not have an initiator (because I don’t know it a priori). Should this throw an error in a DFDL implementation? I suspect it should, though I hope it shouldn’t. -- dfdl-wg mailing list dfdl-wg@ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg -- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com -- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com -- 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 -- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com 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