[DFDL-WG] lengthKind='prefixed' clarification needed

Tim Kimber KIMBERT at uk.ibm.com
Sun Oct 23 15:11:36 CDT 2011


Hi Mike,

I have always assumed that it works like this:
The Prefix region includes leading alignment, leading skip and initiator
The Content region contains the data, and the lengthKind property 
describes how to determine the content length
The Suffix region includes Terminator and trailing alignment.
The lengthKind property describes the content region, and is not examined 
until the Content region is reached. So the element's iniitator, if 
defined, is not included in the length described by the prefix length.

If you view the prefixed length as describing the length of the *element* 
(i..e its entire representation ) then this definition is not intuitive. 
But I have always viewed lengthKind='prefixed' as being like the other 
lengthKinds - it describes the length of the element's *content*.
So it's a consistent definition, but is it useful? I think so. In my 
experience, prefixed lengths tend to be applied to complex elements ( 
structures ) rather than simple values. In such cases, the content of the 
complex element will always be either a sequence group or a choice group, 
and any initiator/terminator can be located on that group..

regards,

Tim Kimber, Common Transformation Team,
Hursley, UK
Internet:  kimbert at uk.ibm.com
Tel. 01962-816742 
Internal tel. 246742




From:   Mike Beckerle <mbeckerle.dfdl at gmail.com>
To:     dfdl-wg at ogf.org
Date:   22/10/2011 19:12
Subject:        [DFDL-WG] lengthKind='prefixed' clarification needed
Sent by:        dfdl-wg-bounces at ogf.org



For agenda/issues list

With respect to lengthKind='prefixed'. I'm concerned that there's a 
complex interaction with initiator/terminator.

Can we have a prefix length and an initiator and terminator as well? If so 
which comes first, and if it's the prefix does the prefix length include 
the length of the initiator and terminator? 

The grammar as written in current draft of spec has the initiator first, 
then the prefix, then the content, and then the terminator. I think this 
is wrong. I mean we can make it work, but it's not a useful, nor intuitive 
behavior. 

If we're going to fix this, I think we should make prefixed an alternative 
to initiator and terminator, so that you can't have both on the element. 

The alternative is to change the order around. Because initiator and 
terminator can each be lists of alternative choices, the only sensible 
composition of prefixed with these has prefix length providing the length 
of a syntax which includes static initiator and terminator fields, which 
are sort of like static padding to be trimmed off the string before 
extracting the value.

E.g., prefix length of 10 preceeding these characters: [[123456]]

<element name='x' type='int' dfdl:initiator="[[" dfdl:terminator="]]" 
dfdl:lengthKind='prefixed' .../>

But,....this is obscure enough that I'd rather make prefix length 
exclusive of initiator/terminator. I.e. Schema Def Error if both are 
specified. 

Rationale: Even if such formats are possible, and even if they do exist 
somewhere, it's possible to model this format differently with hidden 
fields, lengthKind='explicit' etc., so it's not like removing this complex 
interaction of prefix with initiator/terminator reduces DFDL's expressive 
power in any way. 

Summary: To reduce complexity, suggest that lengthKind='prefixed' is 
exclusive of both initiator and terminator properties directly on the same 
element. Schema Definition Error if both are specified.


-- 
Mike Beckerle | OGF DFDL WG Co-Chair 
Tel:  781-330-0412
--
  dfdl-wg mailing list
  dfdl-wg at ogf.org
  http://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





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/dfdl-wg/attachments/20111023/8c470a34/attachment-0001.html 


More information about the dfdl-wg mailing list