[
https://issues.apache.org/jira/browse/DAFFODIL-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17067917#comment-17067917
]
Mike Beckerle edited comment on DAFFODIL-2293 at 3/26/20, 6:10 PM:
-------------------------------------------------------------------
My take on same thing Steve L just said (we were editing same time....)
To make an LSBF test equivalent to your MSBF test, start from your MSB test,
rounded up with X as the additional 5 bits to make it look like whole bytes
(You are allowed to use characters other than 1 and 0 here, and they get
ignored)
<tdml:documentPart type="bits">101{color:#333333}00110 111{color}XXXXX
</tdml:documentPart>
This is 3 bits to skip (which are 101), then an 8 bit character which is
00110111 (character "7").
The equivalent data (to get the same logical information out) but stored LSBF is
<tdml:documentPart type="bits">10111101 XXXXX001</tdml:documentPart>
We put features into TDML to help deal with LSBF data, because this is so hard
to figure out.
{code:java}
<tdml:documentPart type="bits" bitOrder="LSBFirst" byteOrder="RTL"><![CDATA[
XXXXX001 10111101 ]]></tdml:documentPart>{code}
(The CDATA trick is recommended btw so that tools won't line-wrap this stuff)
Looking at this you can see your 00110111 character ("7") in there as
contiguous bits again.
was (Author: mbeckerle):
Bit order LSBF does not mean "reverse the bits". See bitOrder tutorial in
earlier comment.
To make an LSBF test equivalent to your MSBF test, start from your MSB test,
rounded up with X as the additional 5 bits to make it look like whole bytes
(You are allowed to use characters other than 1 and 0 here, and they get
ignored)
<tdml:documentPart type="bits">101{color:#333333}00110 111{color}XXXXX
</tdml:documentPart>
This is 3 bits to skip (which are 101), then an 8 bit character which is
00110111 (character "7").
The equivalent data (to get the same logical information out) but stored LSBF is
<tdml:documentPart type="bits">10111101 XXXXX001</tdml:documentPart>
We put features into TDML to help deal with LSBF data, because this is so hard
to figure out.
{code:java}
<tdml:documentPart type="bits" bitOrder="LSBFirst" byteOrder="RTL"><![CDATA[
XXXXX001 10111101 ]]></tdml:documentPart>{code}
(The CDATA trick is recommended btw so that tools won't line-wrap this stuff)
Looking at this you can see your 00110111 character ("7") in there as
contiguous bits again.
> 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)
