[
https://issues.apache.org/jira/browse/DAFFODIL-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Lawrence resolved DAFFODIL-2019.
--------------------------------------
Resolution: Fixed
Fixed in commit 73bc75630e2d3f8cebd0a5260fd45ca88f6b3ef2
> daf extension property to turn on/off "hexBinary with bits" lengthUnits
> behavior
> --------------------------------------------------------------------------------
>
> Key: DAFFODIL-2019
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2019
> Project: Daffodil
> Issue Type: Bug
> Components: Compatibility, Front End
> Affects Versions: 2.2.0
> Reporter: Michael Beckerle
> Assignee: Steve Lawrence
> Priority: Major
> Fix For: 2.3.0
>
>
> We need a property to turn on/off the daffodil extension where xs:hexBinary
> elements can have length expressed in bits.
> This functionality, as implemented today (Nov 2018) is backwards incompatible
> with the DFDL spec, so is unlikely to be accepted as part of the DFDL
> standard; hence, a way to turn this on and off, with the default setting to
> be off, is needed.
> Specifically, this feature of Daffodil makes the hexBinary infoset contents
> of a hexbinary element dependent on the byteOrder and bitOrder properties.
> Today, in the DFDL spec, xs:hexBinary is independent of these properties,
> making it suddenly dependent on them will change behavior of existing
> schemas. That just won't fly.
> Probably we need to deprecate this functionality and remind users to model
> such data as xs:nonNegativeInteger instead.
> The xs:hexBinary type is really heavily constrained by its role in XSD. E.g.,
> it has length facets. This really makes it much more like a text string than
> any sort of universal blob that can represent binary data. It's behavior
> really should be like text strings. My preferred concept for hexBinary is
> that you parse a text string as iso-8859-1 then convert each character to 2
> hex digits one by one for the infoset. That keeps you out of trouble with
> length facets, etc.
> Users will still want to be able to express that some number of unaligned
> bits, not a multiple of 4 or 8 long, and not starting, nor ending, on a byte
> boundary, is in their data and is not numeric data, so base 10 numeric
> presentation in the infoset is not natural.
> Such data can be best modeled as a xs:nonNegativeInteger. Changing the
> infoset presentation of this data so that it looks like hex, not base 10, is
> not really DFDL's primary purpose. It is always possible to convert to
> xs:hexBinary via dfdl:inputValueCalc, and for unparsing, converted back by
> dfdl:outputValueCalc. Alas this is always going to run into the "value
> element problem", i.e., the data would be like:
> <myDataBits><hexvalue>F34A37</hexvalue></myDataBits>
> where the extra <hexvalue>...</hexvalue> is needed to support the
> dfdl:inputValueCalc/dfdl:outputValueCalc pair, and a hidden group that hides
> the base 10 nonNegativeInteger representation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
