WG agreed that equivalent of Table 16 is needed for lengthKind 'prefixed' and 'delimited', and no longer needed for 'pattern'.

WG agreed that for lengthKind 'prefixed' and lengthUnits 'bits' there is a limitation that you might not be able to unparse exactly what you parsed. This is preferable to disallowing altogether.

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: Steve Hanson/UK/IBM
To: Tim Kimber/UK/IBM@IBMGB
Cc: Alex Wood1/UK/IBM@IBMGB, dfdl-wg@ogf.org
Date: 26/03/2012 11:18
Subject: Re: lengthKind = prefixed and length in bits when serializing...

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