For binary representations of fixed-length numeric types (byte, short, int, long and their unsigned variants, float, double and any simple restrictions of these), dfdl:lengthKind='implicit' means the length (in bits) will match the maximum precision for the base type of the element. For example 32 bits for ‘int’ type (or anything derived from it), 64 bits for ‘long’ type, 8 bits for ‘byte’ etc.  

For simple type elements with text representations (including xs:string type elements) the XSD length information (length or maxLength facets) are used.

For complex type elements that are sequences, 'implicit' means the length is determined by adding up the lengths of the contained children, plus that of any separators or other framing introduced by the sequence itself.

for dfdl:calendarPattern='implicit':
‘implicit’ means the pattern is derived from the XML schema date/time type.

for dfdl:alignment='implicit' ( my words ):
'implicit' means the number is aligned on a byte boundary using the natural size of the binary number based on its XML Schema simple type'

for dfdl:choiceKind='implicit':
When lengthKind='implicit' all alternative branches of the choice are padded to the fixed length of the largest one so that overall the entire choice construct is fixed length

1.  I'm still not clear why 'parsed' is better than 'implicit'. It's a new keyword for DFDL, and seems to overlap a great deal with the meaning of  'implicit'. The justification given for 'parsed' seems to give undue emphasis to the simple type usage. If you look at all of the uses of  'implicit' listed above it has quite a wide range of meanings, but they can be summarized as:
'use the XML Schema definitions instead of the DFDL annotations'  ( lengths of xs:string and binary numbers )
'parse recursively to discover the implicit length'         ( lengths of complex types and choices )

For dfdl:occursCountKind='implicit', the meaning would be
'use the XML Schema definitions instead of the DFDL annotations'  ( xs:minOccurs / xs:maxOccurs instead of dfdl:occursCount/dfdl:stopValue)
'parse recursively to discover the implicit length of the array'         ( use normal parsing rules until the end of the array is found )

2.  The assertion about dfdl:initiatedContent is wrong. If the array is initiated, the number of occurrences can be found using the normal speculative parsing rules. No need for the containing structure or the next sibling to be initiated. If we limit the usage of dfdl:initiatedContent, I think we will introduce inconsistencies in the way that users can control backtracking at a point of uncertainty.

regards,

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

----- Forwarded by Tim Kimber/UK/IBM on 13/08/2009 13:58 -----

From:	dfdl-wg-request@ogf.org
To:	dfdl-wg@ogf.org
Date:	13/08/2009 13:17
Subject:	dfdl-wg Digest, Vol 36, Issue 9

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