Alex What you suggest makes sense. There is an implicit limitation with "prefixed" in that I can parse an element with an odd number of bits (say 13) but be unable to serialize exactly what had been parsed. I don't think there's anything you can do about that, other than use "explicit" with an expression as Tim says. However, I think what you have noted is an issue for all "prefixed" binary rep data, not just lengthUnits "bits". Take a look at Table 16 in section 12.3.5. This was added to handle the same issue for lengthKind "pattern" where all we have is the infoset data. The rightmost column says what to output for binary reps (in practice, it is virtually identical to Table 15 for "implicit" in section 12.3.3). We need this for "prefixed" too. Further, some of the rows in Table 16 are needed for "delimited". Delimited binary data is permitted under a couple of circumstances - when the binary rep is "packed" or "BCD". Section 12.3.2 does not cover what to output for binary reps. Note that errata 3.9 effectively removes Table 16 as "pattern" no longer supports binary rep data. The information in the text column is still needed though, but a closer examination says it is incorrect, as it should take into account dfdl:textOutputMinLength or xs:minLength (see wording in 12.3.2 for "delimited" and 12.3.4 for "prefixed"). Let's discuss on next DFDL WG call. Regards Steve Hanson Architect, Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh@uk.ibm.com tel:+44-1962-815848 From: Tim Kimber/UK/IBM To: Alex Wood1/UK/IBM@IBMGB Cc: Steve Hanson/UK/IBM@IBMGB Date: 23/03/2012 21:55 Subject: Re: lengthKind = prefixed and length in bits when serializing... Fair question. Off the cuff response is - follow lengthKind=implicit rules for lengthKind=prefixed - if that's not what the modeller wants then they can always use lengthKind=explicit with an expression and model the prefix length as a separate element. Then they can use an outputValueCalc expression on the length element to produce whatever result they require. regards, Tim Kimber, Common Transformation Team, Hursley, UK Internet: kimbert@uk.ibm.com Tel. 01962-816742 Internal tel. 246742 From: Alex Wood1/UK/IBM To: Steve Hanson/UK/IBM@IBMGB, Tim Kimber/UK/IBM@IBMGB Date: 23/03/2012 19:33 Subject: lengthKind = prefixed and length in bits when serializing... Hi Steve, Tim. Looking at one of Neil's defects for lengthKind = prefixed Case where lengthUnits = Bits How to we determine what length (in bits) to serialize from the value and logical type ? I could not find a clear definitive answer in the specification. On parsing it is clear that any length is OK as long as it is less than the natural length of the logical type. So the same rules as for lengthKind = explicit, only the length was parsed out of the prefix. On serializing, lengthKind = explicit and implicit have specific lengths to serialize. However lengthKind = prefixed does not have a length to work with. That's ok for lengthUnits = bytes or characters where we know the length of data we are putting in the bitstream. But for lengthKind = bits it's not so obvious. For example an integer value of 1 for an unsignedInt could be serialized in a length anything between 1 and 32 bits. One way would be to find the minimum number of bits we could use to serialized all significant bits of the value. However my instinct is that it ought to follow the lengthKind = implicit rules and serialize the number of bits for the logical types natural length. UnsignedLong 64 UnsignedInt 32 UnsignedShort 16 UnsignedByte 8 Boolean 32 Thoughts ? Kind Regards, - Alex Alex Wood - Software Engineer - WebSphere Message Broker Development Lab Advocate - PMI Mortage MP 211, IBM UK Labs, Hursley Park, Winchester, Hants. SO21 2JN. Tel: Internal 246272, External 01962 816272 Notes: Alex Wood1/UK/IBM@IBMGB e-mail: wooda@uk.ibm.com 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