Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
2.2.0
-
None
Description
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.