[jira] [Closed] (DAFFODIL-870) Verify occursCountKind "implicit" with maxOccurs "unbounded" for hexBinary required elements

["Mike Beckerle (Jira)" <ji...@apache.org>]

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

Mike Beckerle closed DAFFODIL-870.
----------------------------------
    Fix Version/s: 2.7.0
       Resolution: Fixed

IBM 4690 TLOG format works in daffodil now, so this is no longer an issue. 

> Verify occursCountKind "implicit" with maxOccurs "unbounded" for hexBinary required elements
> --------------------------------------------------------------------------------------------
>
>                 Key: DAFFODIL-870
>                 URL: https://issues.apache.org/jira/browse/DAFFODIL-870
>             Project: Daffodil
>          Issue Type: Bug
>          Components: General, QA
>            Reporter: Jessie Chab
>            Priority: Minor
>              Labels: reverify
>             Fix For: 2.7.0
>
>
> See ticket DFDL-732 for details. Mike's note regarding testing the hexBinary use cases:
> Binary data can have delimiters. Spec section 12.3.2 and 12.3.2.2 specifically. Errata 2.97 specifically allows it for hexBinary, and it has been allowed for numbers as well.
> IBM has a point-of-sale terminal format called 4690-TLOG. Google it and it will get you to the github site with the DFDL schema they've written for it. Perhaps grab/derive a test directly from this stuff??
> But it might use the DFDL Byte Value Entites (aka "rawbytes entities") which we don't have an implementation of yet. (They're actually hard to implement.)  
> I am raising a clarification with the workgroup about whether delimited hexBinary can use characters in the delimiters, or must use rawbytes. This would mean dfdl:encoding would need to be used, but that is documented as not being needed for hexBinary, so I am not certain. 
> TLOG uses packed decimal numbers with delimiters, so this is representation='binary' lengthKind='delimited' stuff.  The notion here was not to be too rigid. Sometimes people know their data, and they know that the bytes of the data won't contain certain byte values, so delimiting using specific byte values is allowed. In the case of TLOG, the delimiters are bytes that cannot appear in a packed decimal representation, so delimited works. 
> I really wish we had used more specific names like lengthKind="binaryDelimited", lengthKind="textDelimited", so that we could provide better error checking for the much more common case of delimited with all textual data fields.
> Now, that said, we don't have rawbytes yet. So perhaps this cannot be tested? I'd look at the tlog stuff though.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)