The Specification currently says that
on unparsing dfdl:lengthKind='pattern' behaves like dfdl:lenghtKind='implict'
but since we limited 'implict' to certain logical/representation combinations
this is no longer correct.
Proposals
1. When unparsing complex elements with
dfdl:lengthKind='pattern', the length is the length of the children (same
as 'implicit')
When unparsing simple elements with
dfdl:lengthKind='pattern' the length is the implicit length for those
that have one and length of the data supplied in the infoset converted
to the representation with no padding/filling for the rest.
For string/text and hexbinary/binary
that is reasonable
For number/text/standard and zoned it
is governed by the numberPattern
For number/binary/ binary use
'implicit' lengths
For number/binary/packed or bcd use
minimum number of bytes
For Calendar/text it is governed
by the calendarpattern
For Calendar/binary/packed or bcd use
minimum number of bytes
For Calendar/binary/binarymilliseconds
or binaryseconds use implicit lengths
For Boolean/text use the length
of the true/false rep.
For Boolean/binary use implicit length
(32)
2. A new property dfdl:patternOutputLengthKind
3. We could limit dfdl:lenghtKind 'pattern'
to complex elements so that there is always a lengthKind for child simple
elements but this would introduce 'unnecessary' complex items in the
infoset when there is only one child.
Alan Powell
MP 211, IBM UK Labs, Hursley, Winchester, SO21 2JN, England
Notes Id: Alan Powell/UK/IBM email: alan_powell@uk.ibm.com
Tel: +44 (0)1962 815073
Fax: +44 (0)1962 816898
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