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