July 2015 - dfdl-wg - lists.ogf.org

still no need for fn:error
by Mike Beckerle 03 Aug '16

03 Aug '16

Here's the example as suggested by Jonathan of how to issue an error that I previously was suggesting needed fn:error. I'm convinced this is sufficient and we can avoid the need for fn:error now. <xs:element name="magic_number" type="ex:uint32" dfdl:byteOrder="bigEndian"> <xs:annotation> <xs:appinfo source="*http://www.ogf.org/dfdl/*<http://www.ogf.org/dfdl/dfdl-1.0/> "> <dfdl:assert test="{ (xs:unsignedInt(.) eq *dfdl:hUInt('0xa1b2c3d4')*) | (xs:unsignedInt(.) eq *dfdl:hUInt('0xd4c3b2a1')*) }" message="{ fn:concat( 'Magic number ', dfdl:hexBinary(dfdl:unsignedInt(.)), ' was not 0xA1B2C3D4 (for bigEndian) or 0xD4C3B2A1 (for littleEndian).' }" /> <dfdl:setVariable ref="ex:bOrd">{ xs:unsignedInt(.) }<dfdl:setVariable> </xs:appinfo> </xs:annotation> </xs:element> -- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com

2 11

clarification on choice unparsing and empty sequences
by Mike Beckerle 11 Aug '15

11 Aug '15

The spec language around how choice branches are resolved when unparsing suggests that each branch must have an element in it somewhere. On unparsing there is the question of how one identifies the appropriate schema choice branch corresponding to the data in the infoset. This is complicated by the fact that the children may not be elements. They may themselves be sequences or choices.The selection of the choice branch is as follows: The element in the infoset is used to search the choice branches in the schema, in schema definition order, but without looking inside any complex elements. If the element occurs in a branch, then that branch is selected and if subsequently a processing error occurs, this selection is not revisited (that is, there is no backtracking). To avoid any unintended behavior, all the children of a choice can be modeled as elements. However, that passage of the spec seems incomplete now to me. Though at the time it was written and reviewed it seemed to be the solution to the issue. It does imply that each model group in a choice branch has to have an element somewhere, but I couldn't find that statement explicitly in the spec, and the spec does say empty model groups are specifically allowed. 14.1 Empty Sequences A sequence having no children is syntactically legal in DFDL. In the data stream, such a sequence can have non-zero length *LeftFraming* and *RightFraming* regions, but the SequenceContent region in between must be empty. It is a processing error if the SequenceContent region of an empty sequence has non-zero length when parsing. This leaves open the issue of hidden groups e.g., <sequence dfdl:hiddenGroupRef="mygroup"/> is an empty sequence? Or does the hidden group count as if there really are children of this sequence? I suspect the latter, but need to see how others have interpreted this. XML schema does not define an empty sequence that is the content model of a complex type definition as effective content so any DFDL annotations on such a construct would be ignored. It is a schema definition error if the empty sequence is the content model of a complex type, or if a complex type has nothing in its content model at all. That makes clear that both these are SDE: <complexType><sequence/></complexType> <complexType></complexType> But it leaves many scenarios unclear still. Consider this schema fragment: .... <choice> <sequence dfdl:terminator=";"/> <element name="foo"/> </choice> <element name="bar"/> .... If we are unparsing and the infoset is just <bar> then we can compute that finding <bar> in the infoset means the first branch is selected. So we would unparse that and output a ";". However, if there is true ambiguity like: <choice> <sequence dfdl:terminator=";"/> <sequence dfdl:terminator="/"/> <element name="foo"/> </choice> <element name="bar"/> That's effectively saying on parse either a ";" or a "/" may be found. On unparse, there is nothing to guide which choice branch other than telling us if <bar> is found, that the <foo> element branch is NOT selected. However, it is ok to just output the first always (;) if the infoset has a <bar> element. However, I wanted to check and see what others interpretation of the spec is for this issue. Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com Please note: Contributions to the DFDL Workgroup's email discussions are subject to the OGF Intellectual Property Policy <http://www.ogf.org/About/abt_policies.php>

2 1

OGF DFDL WG Call 2015-07-21 - cancelled
by Steve Hanson 21 Jul '15

21 Jul '15

Sorry for late cancellation, but something has come up which means I am no longer available. Next meeting is August 11th. Regards Steve Hanson Architect, IBM DFDL Co-Chair, OGF DFDL Working Group Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848

1 0

Cancelled: DFDL Working Group Call
by Steve Hanson 21 Jul '15

21 Jul '15

Sorry for late cancellation but something has come up which means I am no longer available.

1 0

Confirmed: DFDL Working Group Call (21 Jul 16:00 GDT in IBM Hursley DE3S09)
by Steve Hanson 20 Jul '15

20 Jul '15

OGF DFDL WG weekly call dial-in details. Passcode for Participants: 5381214 Canada Toll-Free 888-426-6840 China Toll-Free 10-800-711-1071 CHINA NETCOM GROUP USERS China Toll-Free 10-800-110-0996 CHINA TELECOM SOUTH USERS France Toll-Free 0800-94-0558 Germany Toll-Free 0800-000-1018 India Toll-Free 000-800-100-1176 Ireland Toll-Free 1-800-943-427 Israel Toll-Free 1-809-417-783 United Kingdom Caller Paid 0-20-30596451 United Kingdom Toll-Free 0800-368-0638 USA Caller Paid 215-861-6239 USA Toll-Free 888-426-6840 Other international numbers available - e-mail smh(a)uk.ibm.com. OGF DFDL Home: http://www.ogf.org/dfdl Redmine DFDL: http://redmine.ogf.org/projects/dfdl-wg DFDL Getting Started: http://www.ibm.com/developerworks/library/se-dfdl/ DFDL 1.0 Spec: http://www.ogf.org/documents/GFD.207.pdf Confirming call. Agenda to follow.

1 0