clarification needed on lengthKind='pattern' inside complexType element with lengthKind='delimited'
If I nest an element having lengthKind='pattern' inside a complexType element with lengthKind='delimited' I wanted to clarify the behavior of the pattern matching. I've been assuming the pattern does NOT get stopped by occurrances of the delimiters. That is, the pattern scan is in no way adapted to being inside of a delimited context. The alternative would be that the lengthKind="pattern" element's pattern would be augmented by something allowing it to stop if the delimiter were encountered, possibly taking even escape schemes into account, etc. This does not seem worth it to me. It seems like the behavior for lengthKind='pattern' should be greedy, and blind to enclosing delimiters. Precedent is that lengthKind="explcit" is also blind to enclosing delimiters. Comments? -- Mike Beckerle | OGF DFDL WG Co-Chair Tel: 781-330-0412
Mike The latest internal draft of the spec says: "When dfdl:lengthKind is 'pattern', it means that delimiter scanning is turned off and in-scope delimiters are not looked for within or between elements." This is from errata 3.3: "3.3. Section 12.3. Clarify that when property is lengthKind 'explicit', 'implicit' (simple only), 'prefixed' or 'pattern', it means that delimiter scanning is turned off and in-scope delimiters are not looked for within or between elements." Regards Steve Hanson Architect, 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: 24/10/2012 20:16 Subject: [DFDL-WG] clarification needed on lengthKind='pattern' inside complexType element with lengthKind='delimited' Sent by: dfdl-wg-bounces@ogf.org If I nest an element having lengthKind='pattern' inside a complexType element with lengthKind='delimited' I wanted to clarify the behavior of the pattern matching. I've been assuming the pattern does NOT get stopped by occurrances of the delimiters. That is, the pattern scan is in no way adapted to being inside of a delimited context. The alternative would be that the lengthKind="pattern" element's pattern would be augmented by something allowing it to stop if the delimiter were encountered, possibly taking even escape schemes into account, etc. This does not seem worth it to me. It seems like the behavior for lengthKind='pattern' should be greedy, and blind to enclosing delimiters. Precedent is that lengthKind="explcit" is also blind to enclosing delimiters. Comments? -- Mike Beckerle | OGF DFDL WG Co-Chair Tel: 781-330-0412 -- 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 strongly believe that the behaviours of the various lengthKind enums should be completely independent of one another. While calculating the length of an element's content, delimiters should be ignored unless lengthKind='delimited' or 'endOfParent'. regards, Tim Kimber, DFDL Team, Hursley, UK Internet: kimbert@uk.ibm.com Tel. 01962-816742 Internal tel. 37246742 From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: dfdl-wg@ogf.org, Date: 24/10/2012 20:16 Subject: [DFDL-WG] clarification needed on lengthKind='pattern' inside complexType element with lengthKind='delimited' Sent by: dfdl-wg-bounces@ogf.org If I nest an element having lengthKind='pattern' inside a complexType element with lengthKind='delimited' I wanted to clarify the behavior of the pattern matching. I've been assuming the pattern does NOT get stopped by occurrances of the delimiters. That is, the pattern scan is in no way adapted to being inside of a delimited context. The alternative would be that the lengthKind="pattern" element's pattern would be augmented by something allowing it to stop if the delimiter were encountered, possibly taking even escape schemes into account, etc. This does not seem worth it to me. It seems like the behavior for lengthKind='pattern' should be greedy, and blind to enclosing delimiters. Precedent is that lengthKind="explcit" is also blind to enclosing delimiters. Comments? -- Mike Beckerle | OGF DFDL WG Co-Chair Tel: 781-330-0412 -- 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
participants (3)
-
Mike Beckerle -
Steve Hanson -
Tim Kimber