[
https://issues.apache.org/jira/browse/DAFFODIL-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17067914#comment-17067914
]
Steve Lawrence edited comment on DAFFODIL-2293 at 3/26/20, 6:06 PM:
--------------------------------------------------------------------
Yeah, LSBF is sort of weird and hard to wrap your head around at first. At a
high level the way it works is bytes are read left to right just like normal,
but bits within those bytes are read right to left.
For {{a}}, if we want a to have a 3-bit value of 5, thats binary {{101}}, so
the first byte needs to look like this:
{code}
xxxxx101
{code}
Notice how the bits start at the right side of the byte instead of the left
like normal.
Now we need to fill in the rest of the bits for the value of b. We want b to
have a value of the character '7' (that's 55 in decimal, or {{00110111}} in
binary). We still need to fill in those 5 bits from the first byte, so we take
the right most bits of our 55 in binary (or {{10111}}) and replace that with
our xxx's above, to get this:
{code}
10111101
{code}
But we now have 3 bits still left over from the left side of our character '7'
(that's bits {{001}}). We've run out of space in our first byte, so those are
added to the next byte. And as before, they go on the right side of the byte.
So we get this:
{code}
10111101 xxxxx001
{code}
And then there's just 5 bits of nothing left over in the second byte. You could
put some pad bits in there, but Daffodil will complain that there's left over
data after the parse. So we have a way to specify the bytes in the reverse
order so daffodil knows those padding bits aren't needed: i.e.:
{code:xml}
<tdml:documentPart type="bits" bitOrder="LSBFirst" byteOrder="RTL">001
10111101</tdml:documentPart>
{code}
With it specified like that, Daffodil should do the right thing and put the
bits in the correct order in the way the schema expects them.
To maybe provide a little extra intution about what's going on here, notice the
RTL bits that we provided in the document part:
{code}
001 10111101
{code}
If we take those same bits but slide the space separator over a little bit,
like this:
{code}
00110111 101
{code}
It's maybe more clear to see that what this really is doing. If we read the
bits right to left, we first have bits {{101}} (our 5 value) followed by bits
{{00110111}} our 55 value. So that's really what this LSBF stuff is all about.
We're just imagining the stream of bytes are coming in from right to left
rather than the standard way of reading them left to right.
was (Author: slawrence):
Yeah, LSBF is sort of weird and hard to wrap your head around at first. At a
high level the way it works is bytes are read left to right just like normal,
but bits within those bytes are read right to left.
For {{a}}, if we want a to have a 3-bit value of 5, thats binary {{101}}, so
the first byte needs to look like this:
{code}
xxxxx101
{code}
Notice how the bits start at the right side of the byte instead of the left
like normal.
Now we need to fill in the rest of the bits for the value of b. We want b to
have a value of the character '7' (that's 55 in decimal, or {{00110111}} in
binary). We still need to fill in those 5 bits from the first byte, so we take
the right most bits of our 55 in binary (or {{10111}}) and replace that with
our xxx's above, to get this:
{code}
10111101
{code}
But we now have 3 bits still left over from the left side of our character '7'
(that's bits {{001}}). We've run out of space in our first byte, so those are
added to the next byte. And as before, they go on the right side of the byte.
So we get this:
{code}
10111101 xxxxx001
{code}
And then there's just 5 bits of nothing left over in the second byte. You could
put some pad bits in there, but Daffodil will complain that there's left over
data after the parse. So we have a way to specify the bytes in the reverse
order so daffodil knows those padding bits aren't needed: i.e.:
{code:xsd}
<tdml:documentPart type="bits" bitOrder="LSBFirst" byteOrder="RTL">001
10111101</tdml:documentPart>
{code}
With it specified like that, Daffodil should do the right thing and put the
bits in the correct order in the way the schema expects them.
To maybe provide a little extra intution about what's going on here, notice the
RTL bits that we provided in the document part:
{code}
001 10111101
{code}
If we take those same bits but slide the space separator over a little bit,
like this:
{code}
00110111 101
{code}
It's maybe more clear to see that what this really is doing. If we read the
bits right to left, we first have bits {{101}} (our 5 value) followed by bits
{{00110111}} our 55 value. So that's really what this LSBF stuff is all about.
We're just imagining the stream of bytes are coming in from right to left
rather than the standard way of reading them left to right.
> Too many bits in xs:string
> --------------------------
>
> Key: DAFFODIL-2293
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2293
> Project: Daffodil
> Issue Type: Question
> Reporter: Alexander Deutschmann
> Assignee: Baumann Kurt
> Priority: Major
> Fix For: 2.6.0
>
>
> Hello everyone,
> i have the following schema:
> {code:xml}
> <xs:complexType name="statusReportDetails">
> <xs:sequence>
> <xs:element name="state" type="abc:stateenum"
> dfdl:length="4" />
> <xs:element name="indicators" type="abc:indicators"
> dfdl:length="16" />
> <xs:element name="v" type="v" dfdl:length="10" />
> <xs:element name="driverId" type="xs:string"
> dfdl:lengthKind="explicit" dfdl:length="128" dfdl:alignment="8" />
> </xs:sequence>
> </xs:complexType>
> {code}
> And the related bitstream:
> {code:java}
> 0101 -> Enum
> 0000110000000001 -> indicators
> 0001100100 -> v
> 0000110001001100010011000100110001001100100011001000110010001100100011001100110011001100110011001100110100001101000011010000110100
> -> driverId
> {code}
> The driverId has 130 bits and not the 128. bits which is defined in the
> schema.
> My question is where comes the first two bits ? I know it is an configuration
> mistake or something like that.
> I hope someone can help me.
> Thank you.
> Alex
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
