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