[DFDL-WG] Clarification: zero-bit-long integer parses to value 0, or parse-error or?

[Steve Hanson]

Yes, but be careful that the reps are being established in the correct 
order.

Empty rep takes precedence over normal rep. So in your example when 
expression is zero, you have empty rep. If the element had a default 
value, you would apply it. If no default, you move on to see if zero 
length can be normal rep. For an int (of any flavour) it can't (as you 
say, there are minimum lengths from the table). So it is a parse error. 

HTH
 
Steve Hanson
IBM Hybrid Integration, Hursley, UK
Architect, IBM DFDL
Co-Chair, OGF DFDL Working Group
smh at uk.ibm.com
tel:+44-1962-815848
mob:+44-7717-378890
Note: I work Tuesday to Friday 



From:   Mike Beckerle <mbeckerle.dfdl at gmail.com>
To:     Steve Hanson <smh at uk.ibm.com>
Cc:     DFDL-WG <dfdl-wg at ogf.org>
Date:   20/03/2020 14:21
Subject:        [EXTERNAL] Re: [DFDL-WG] Clarification: zero-bit-long 
integer parses to value 0, or parse-error or?




Thanks, I was actually thinking this was in a table somewhere also, and I 
did find it.

Table 22 says the minimum length for a binary signed integer is 2 bits, 
for unsigned 1. 

So definitely a parse error, and symmetrically, and unparse error if 
length is 0 for an int/unsignedint when unparsing. 

Mike Beckerle | OGF DFDL Workgroup Co-Chair | Owl Cyber Defense | 
www.owlcyberdefense.com
Please note: Contributions to the DFDL Workgroup's email discussions are 
subject to the OGF Intellectual Property Policy



On Thu, Mar 19, 2020 at 7:28 PM Steve Hanson <smh at uk.ibm.com> wrote:
This is covered by section 9.3.2 (establishing representation) and section 
9.5 (evaluation order). 

Your integer is not nillable, so can't have nil rep. Assuming compliance 
with dfdl:emptyValueDelimiterPolicy it therefore has empty representation. 
Assuming this is a local element with minOccurs-=1 implicitly, and no 
default value, it is a parsing error. Section 9.5 says the assert will 
never be executed as it is lower down the evaluation order. 

Regards
 
Steve Hanson 
IBM Hybrid Integration, Hursley, UK
Architect, IBM DFDL
Co-Chair, OGF DFDL Working Group
smh at uk.ibm.com
tel:+44-1962-815848
mob:+44-7717-378890
Note: I work Tuesday to Friday 



From:        Mike Beckerle <mbeckerle.dfdl at gmail.com> 
To:        DFDL-WG <dfdl-wg at ogf.org> 
Date:        19/03/2020 22:50 
Subject:        [EXTERNAL] [DFDL-WG] Clarification: zero-bit-long integer 
parses to value 0, or parse-error or? 
Sent by:        "dfdl-wg" <dfdl-wg-bounces at ogf.org> 




Consider: 
<xs:element name="spare" dfdl:length="{ $tns:WordPaddingBits }">
 <xs:simpleType dfdl:lengthKind="explicit">
  <xs:annotation>
   <xs:appinfo source="http://www.ogf.org/dfdl/">
     <dfdl:assert test="{ . eq 0 }" />
   </xs:appinfo>
  </xs:annotation>
  <xs:restriction base="xs:unsignedInt">
   <xs:enumeration value="0" />
  </xs:restriction>
 </xs:simpleType>
</xs:element>

Now, suppose the variable tns:WordPaddingBits has value 0. 
So this padding integer will be length 0 (this binary data with 
lengthUnits bits). 
Currently, Daffodil gives a runtime SDE on this. The assert test 
expression complains that "." has no value.
I would claim this should either provide a value of 0 for this integer, or 
it should be a parse error because you must have at least 1 bit.

Thoughts? 
Mike Beckerle | OGF DFDL Workgroup Co-Chair | Owl Cyber Defense | 
www.owlcyberdefense.com (Tresys is now part of Owl) 
Please note: Contributions to the DFDL Workgroup's email discussions are 
subject to the OGF Intellectual Property Policy 

--
 dfdl-wg mailing list
 dfdl-wg at ogf.org
 https://www.ogf.org/mailman/listinfo/dfdl-wg 


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20200321/bedddc6a/attachment-0001.html>