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