[
https://issues.apache.org/jira/browse/DAFFODIL-1401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Beckerle updated DAFFODIL-1401:
------------------------------------
Priority: Minor (was: Major)
> eliminate need for dfdl:encoding and dfdl:byteOrder and dfdl:bitOrder for
> model groups and elements that don't need it.
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: DAFFODIL-1401
> URL: https://issues.apache.org/jira/browse/DAFFODIL-1401
> Project: Daffodil
> Issue Type: Improvement
> Components: Middle "End"
> Reporter: Mike Beckerle
> Priority: Minor
>
> If you look at the pcap schema. There's a need to have dfdl:byteOrder on a
> bunch of the elements and sequences up until it gets to the magic number
> element.
> I am not thrilled about having to add these byteOrder properties to these
> elements and sequences.
> Optimizing this requirement out requires that we recognize that no alignment
> other than to byte boundaries is needed, which means there is a known charset
> that has 8-bit mandatory alignment, or there are no delimiters, and there
> must be only alignment (in Bits) that is a multiple of 8 bits.
> And if the component is an element of simple type, then it must not be binary
> numeric of more than one byte.
> In that case, there's no way an alignment region can be needed other than one
> that skips forward to a byte boundary, so byte order isn't meaningful for the
> component.
> But even that isn't enough. If an element is an array, and complex type, and
> the byte order varies inside child elements of the array, then the array
> could start with byte order say, bigEndian, same as what precedes the array
> contextually, but the last thing in it might be littleEndian, so when the
> next repetition is encountered, the current state is littleEndian, not
> bigEndian.
> It's actually worse than that. The array element and its model-group might
> have no byteOrder needs, but a child inside it may need say, bigEndian. a
> later sibling of that needs littleEndian. In other words, we can't figure
> this out from looking at the starting context of the array.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)