- dfdl-wg - lists.ogf.org

Spec errata 3.3
by Mike Beckerle 23 Feb '12

23 Feb '12

----- Message from Steve Hanson <smh(a)uk.ibm.com> on Tue, 21 Feb 2012 17:24:59 +0000 ----- To be discussed on next DFDL WG call. As a result of action 136, the spec errata document currently says: 3.3. Section 12.3. Clarify that when property is lengthKind 'explicit', 'implicit', 'prefixed' or 'pattern', it means that delimiter scanning is turned off and in-scope delimiters are not looked for within or between elements. Consequently remove the last paragraph of section 5.2.2 starting "It is a processing error when a fixed-length string is found to have a number of characters not equal to the fixed number". It has been pointed out that for a complex element with lengthKind 'implicit', turning off in-scope delimiters is not a consistent behaviour. Even though implicit means that the length is defined by the child content, this is still subject to constraints imposed by the parent. Further, as lengthKind 'implicit' is the implied lengthKind for local sequences and choices, it should be possible to wrap such a sequence or choice in an element with lengthKind 'implicit' and no framing, and experience no behaviour change in parsing other than the addition to the infoset of the element. The ability to selectively switch off in-scope delimiters is something that could be useful for both 'implicit' and 'delimited' lengthKinds, and if so could be added post 1.0 as a separate control. The proposal is to change errata 3.3 to read: 3.3. Section 12.3. Clarify that when property lengthKind is 'explicit', 'prefixed' or 'pattern', then delimiter scanning is turned off and in-scope delimiters are not looked for within or between elements. Clarify that when property lengthKind is 'implicit' and type is simple, then delimiter scanning is turned off and in-scope delimiters are not looked for within or between elements. Clarify that when property lengthKind is 'implicit' and type is complex, then delimiter scanning is not turned off and in-scope delimiters are looked for. Consequently remove the last paragraph of section 5.2.2 starting "It is a processing error when a fixed-length string is found to have a number of characters not equal to the fixed number". Regards Steve Hanson Architect, Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 ________________________________ 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

1 0

OGF DFDL WG Call Minutes 2012-02-21
by Mike Beckerle 23 Feb '12

23 Feb '12

Please find minutes from the above call on GridForge at https://forge.ogf.org/sf/docman/do/downloadDocument/projects.dfdl-wg/docman… Errata document has been updated to version 8 and may be found via https://forge.ogf.org/sf/projects/dfdl-wg Regards Steve Hanson Architect, DFDL, IBM SWG Co-Chair, OGF DFDL Working Group Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 ________________________________ 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

1 0

Clarification on Escape Schemes being Optional
by Mike Beckerle 21 Feb '12

21 Feb '12

Are escape schemes entirely optional in DFDL v1.0, or just "defineEscapeScheme" named ones? -- Mike Beckerle | OGF DFDL WG Co-Chair Tel: 781-330-0412

1 0

test message 2
by Mike Beckerle 21 Feb '12

21 Feb '12

Please ignore. -- Mike Beckerle | OGF DFDL WG Co-Chair Tel: 781-330-0412

1 0

Testing mailing list responsiveness
by Steve Hanson 21 Feb '12

21 Feb '12

Regards Steve Hanson Architect, Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 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

1 0

test message
by Mike Beckerle 21 Feb '12

21 Feb '12

Please ignore this message. -- Mike Beckerle | OGF DFDL WG Co-Chair Tel: 781-330-0412

1 0

OGF DFDL WG Call Agenda 2012-02-21
by Steve Hanson 21 Feb '12

21 Feb '12

Please find agenda attached for the above call (there is a problem with GridForge so I can't post the document there) Regards Steve Hanson Architect, Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848

1 0

Fw: Fw: * DFDL Errata* Clarification: Limitations on use of endOfParent
by Steve Hanson 21 Feb '12

21 Feb '12

Let's try and close on this today. Need to agree on list of restrictions below, and decide whether 'endOfParent' is allowed on root element (to handle case where data is ended by EOF). Regards Steve Hanson Architect, Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 ----- Forwarded by Steve Hanson/UK/IBM on 21/02/2012 10:45 ----- From: Steve Hanson/UK/IBM To: dfdl-wg(a)ogf.org Date: 31/01/2012 17:35 Subject: Fw: [DFDL-WG] Fw: * DFDL Errata* Clarification: Limitations on use of endOfParent Here are the updates to the restrictions that we discussed on the call. Action 165 raised. Constraints on element lengthKind 'endOfParent'... - element maxOccurs = 1 - no terminator on element - no trailingSkip on element - if element is in a sequence - sequence must be the content of a complex type - element must be the last object in the sequence - separatorPosition of sequence must not be 'postFix' - sequenceKind of sequence must be 'ordered' - no terminator on sequence - no trailingSkip on sequence - no floating elements in the sequence - if element is in a choice - if choiceLengthKind is 'implicit' - choice must be the content of a complex type - no terminator on choice - no trailingSkip on choice - parent element lengthKind must not be 'implicit' or 'delimited' - not sensitive to any in-scope markup Notes: - complex element can have 'endOfParent', & its last child element can be any lengthKind including 'endOfParent' - element must be the last thing in its box - a box is defined as a portion of the data stream that has an established length prior to the parsing of its children - element with lengthKind 'explicit', 'prefixed', 'pattern' & no (sequence right framing or sequence postfix separator or choice right framing) - choice with choiceLengthKind 'explicit' Regards Steve Hanson Architect, Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 ----- Forwarded by Steve Hanson/UK/IBM on 31/01/2012 16:54 ----- From: Steve Hanson/UK/IBM To: Mike Beckerle <mbeckerle.dfdl(a)gmail.com> Cc: dfdl-wg(a)ogf.org Date: 23/01/2012 17:53 Subject: Re: [DFDL-WG] Fw: * DFDL Errata* Clarification: Limitations on use of endOfParent I have typically used 'implicit' for this because the children of the root element should match the data leaving no bytes unconsumed. Alternatively using 'delimited' should be equivalent, you are never actually scanning. However when the last child is endOfParent according to the rules below I can't use 'implicit' or 'delimited'....so in that scenario I am stuck. Need a rethink. Regards Steve Hanson Architect, Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 From: Mike Beckerle <mbeckerle.dfdl(a)gmail.com> To: Steve Hanson/UK/IBM@IBMGB Cc: dfdl-wg(a)ogf.org Date: 23/01/2012 17:00 Subject: Re: [DFDL-WG] Fw: * DFDL Errata* Clarification: Limitations on use of endOfParent Only question I have is on "endOfParent" not being allowed on root element. If you have a DFDL implementation processing message buffers, and the root element's content ends at the end of the buffer/end-of-data, how do we express that? I expected that to be end-of-parent, the notion being that there's an implicit parent for all content, which has an end which is the true end-of-data. ...mikeb On Mon, Jan 23, 2012 at 6:19 AM, Steve Hanson <smh(a)uk.ibm.com> wrote: ----- Forwarded by Steve Hanson/UK/IBM on 23/01/2012 11:16 ----- From: Steve Hanson/UK/IBM To: Mike Beckerle <mbeckerle.dfdl(a)gmail.com>, Tim Kimber/UK/IBM Date: 18/01/2012 16:26 Subject: * DFDL Errata* Clarification: Limitations on use of endOfParent As agreed on WG extra call on 18th Jan. Will be raised as a separate issue on next DFDL WG call. Constraints on element lengthKind 'endOfParent'... - element maxOccurs = 1 - no terminator on element - if element is in a sequence - separatorPolicy of sequence must not be 'postFix' - sequenceKind of sequence must be 'ordered' - no floating elements in the sequence - must be the 'last' in the sequence statically ** - if element is in a choice it is always 'last' statically ** - parent element lengthKind must not be 'implicit' or 'delimited' - if element is complex then all possible 'last' elements ** must also be 'endOfParent' - not sensitive to any in-scope markup - not allowed on root element ** Need a concise description of walking the content of a complex element and building the list of 'last elements'. Involves factoring out local sequences and coping with choices. Regards Steve Hanson Architect, Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 From: Steve Hanson/UK/IBM To: Mike Beckerle <mbeckerle.dfdl(a)gmail.com> Cc: Tim Kimber/UK/IBM@IBMGB Date: 08/11/2011 18:22 Subject: Re: Coping with Character code U+0000 - and how to end-of-parent in an array Hi Mike For the record, I knew we said something about U+0000 - it's in section 5... String – In DFDL a string can contain any character codes. None are reserved. (Including the character with character code U+0000, which is not permitted in XML documents.) After discussion with Sandy Gao, this is what we wrote in the DFDL to XDM mapping document: Note: SimpleElement [datavalue] values may contain characters that are illegal in XML, for example, DFDL strings can contain the character code 0 (zero) within them, but XML does not allow this character code in any XML content even if it is represented as a character entity. Nevertheless, a DFDL described string is mapped to an XDM string data value. and later for the actual mapping to XDM: SimpleElement: If the value of [datavalue] is special value “nil”, then the empty string, otherwise the value of [datavalue] converted to its canonical lexical representation. On to your examples (and assuming separatorPosition is 'infix')... You are right about the first (endOfParent) example being odd. This example would work fine if the lengthKind was 'delimited'. Remember that the 'explicit' length of the parent element creates a box which scopes the delimited behaviour. The second (delimited) works fine. endOfParent and delimited behave almost identically most of the time. When the element is an array, this looks to be one of the differences. I am thinking that endOfParent should not be allowed when maxOccurs > 1. Regards Steve Hanson Architect, Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 From: Mike Beckerle <mbeckerle.dfdl(a)gmail.com> To: Steve Hanson/UK/IBM@IBMGB, Tim Kimber/UK/IBM@IBMGB Date: 08/11/2011 17:02 Subject: Coping with Character code U+0000 - and how to end-of-parent in an array We have this incompatiability with XML infoset around U+0000 aka NUL. However, one can model data containing character code U+0000 in the content as an array of strings with NUL termination. That is, we split the string on the NUL characters so as to avoid putting them in the infoset. So I tried to do this and ran into issues. E.g., if data contains a string of length 80, but inside it the character code 0 can appear, then this could be modeled as: <element name="stringsWithNul" dfdl:lengthKind="fixed" dfdl:length="80"> <sequence dfdl:separator="%x0000;"> <element name="substring" type="string" maxOccurs="80" dfdl:lengthKind="endOfParent" />  </sequence> </element> Problem: is that use of endOfParent length kind right? It's the last thing in the group, but the same element decl also describes the prior elements. If there are no NULs in the string, then endOfParent is exactly what you want. There will be only one substring, it will have all 80 characters. But if there are NULs in the middle, then you want the earlier array elements to be delimited by the sequence's separators, and only the last element to be delimited by endOfParent. This semantics where the parent is providing the constraints on length, but sometimes its separator, just for the last thing it's endOfParent, is not something we can express I believe. I was actually even unclear on this one: If the data 'string' has a terminator of ! then perhaps: <element name="stringsWithNul" dfdl:lengthKind="delimited" dfdl:terminator="!"> <sequence dfdl:separator="%x0000;"> <element name="substring" type="string" maxOccurs="unbounded" dfdl:lengthKind="delimited"/>  </sequence> </element> Is the array element delimited? Is that the right length kind for this situation? Thanks for comments ...mikeb ...mikeb 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 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 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 -- dfdl-wg mailing list dfdl-wg(a)ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg -- Mike Beckerle | OGF DFDL WG Co-Chair Tel: 781-330-0412 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 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 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

1 0

OGF DFDL WG Call Minutes 2012-02-14
by Steve Hanson 15 Feb '12

15 Feb '12

Please find minutes from the above call on GridForge at https://forge.ogf.org/sf/docman/do/downloadDocument/projects.dfdl-wg/docman… Errata document has been updated to version 8 and may be found via https://forge.ogf.org/sf/projects/dfdl-wg Regards Steve Hanson Architect, DFDL, IBM SWG Co-Chair, OGF DFDL Working Group Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848

1 0

Fw: Issue 140 and empty string - question on escape schemes as empty-string qualifiers
by Steve Hanson 14 Feb '12

14 Feb '12

Not sure that we had discussed this on a WG call, so adding to today's agenda. There's a potential spec update needed. Regards Steve Hanson Architect, Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 ----- Forwarded by Steve Hanson/UK/IBM on 14/02/2012 13:30 ----- From: Steve Hanson/UK/IBM To: Mike Beckerle <mbeckerle.dfdl(a)gmail.com> Cc: Tim Kimber/UK/IBM@IBMGB Date: 31/01/2012 13:58 Subject: Re: Issue 140 and empty string - question on escape schemes as empty-string qualifiers Mike - some replies below Regards Steve Hanson Architect, Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 From: Mike Beckerle <mbeckerle.dfdl(a)gmail.com> To: Steve Hanson/UK/IBM@IBMGB, Tim Kimber/UK/IBM@IBMGB Date: 30/01/2012 20:13 Subject: Issue 140 and empty string - question on escape schemes as empty-string qualifiers I think we forgot about escape schemes and how they are used to quote around empty strings, and possibly nil indicators, or I'd like clarification anyway. E.g., <dfdl:defineEscapeScheme name="quotedStrings"> <dfdl:escapeScheme escapeBlockStart="'" escapeBlockEnd="'" escapeKind="escapeBlock" /> </dfdl:defineEscapeScheme> <element name="x" type="string" nillable="true" dfdl:nilValue="nil" dfdl:escapeSchemeRef="quotedStrings"/> Now, if data is [nil, nil] I get two nils. <x xsi:nil="true/><x xsi:nil="true/> What if data is ['nil','nil'] - either I still get two nils, or I get two non-nil strings with "nil" as their contents: <x>nil</x><x>nil</x> Which is it? SMH: According to the property precedence order in section 22 of the spec, the escape scheme is applied before nil value processing when parsing, and after nil value processing on unparsing. That is independent of the nilKind. So in your example you would get two nils in the infoset. Similarly, assume please that empty string matches the syntax for empty per initiator/terminator and emptyValueDelimiterPolicy, Now if I have <element name="myString" type="string" minOccurs="0", maxOccurs="2" dfdl:escapeSchemeRef="quotedStrings"> It's all optional, so if the data is ['',''] then I either get nothing in the infoset (because empty creates nothing for optionals), or I get two empty strings in the infoset. Which is it? SMH: I would look at this from the unparsing angle. If there is nothing in the infoset then I would expect to see nothing in the data, I would not expect to see escaped nothing. That's true if generateEscapeBlock is 'always' or 'whenNeeded'. If I had an empty string in the infoset then I would expect it to be escaped in the data if I said 'always' but not if I said 'whenNeeded' (because %ES; is not allowed as a delimiter or as a value extraEscapedCharacters, so escaping empty string can never be needed.) From this, the only way I could get '' in the data would be if I had escaped an empty string. Therefore on parsing, I would treat '' as an escaped empty string and add empty string to infoset. This sounds right to me. In our action 140 document, we have defined 'empty' to mean that the returned length (however obtained) is 0. If I encounter escape characters than I would claim that slot in the data is not 'empty'. We should check that this is consistent with how emptyValueDelimiterPolicy is applied. For parsing section 22 has this correct, and emptyValueDelimiterPolicy is examined before escape scheme applied. But for unparsing section 22 has it the wrong way round - the property should be applied after any escaping/padding has taken place. 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 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

1 0