Michael Beckerle created DAFFODIL-2019:
------------------------------------------
Summary: 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
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)
