[jira] [Assigned] (DAFFODIL-2019) daf extension property to turn on/off "hexBinary with bits" lengthUnits behavior

["Steve Lawrence (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DAFFODIL-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steve Lawrence reassigned DAFFODIL-2019:
----------------------------------------

    Assignee: Steve Lawrence

> 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
>
> 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)