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@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:
Steve Hanson <smh@uk.ibm.com>
Cc:
DFDL-WG <dfdl-wg@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@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
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