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@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@uk.ibm.com
tel:+44-1962-815848
mob:+44-7717-378890
Note: I work Tuesday to Friday

From: Mike Beckerle <mbeckerle.dfdl@gmail.com>
To: DFDL-WG <dfdl-wg@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@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@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