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