Clarification: zero-bit-long integer parses to value 0, or parse-error or?
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 <http://www.ogf.org/About/abt_policies.php>
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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ogf.org_mailman_listinfo_dfdl-2Dwg&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=AJa9ThEymJXYnOqu84mJuw&m=mvRgmUZqqByvkZrWl9f4DONoCl3A8QR3HuliCUCmavs&s=AaalvDoqwfJgjWFrMa43i3Cqzxm_DXRA5jSZPaFoUY8&e= 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
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 <http://www.ogf.org/About/abt_policies.php> 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* <http://www.ibm.com/developerworks/library/se-dfdl/index.html> Co-Chair, *OGF DFDL Working Group* <http://www.ogf.org/dfdl/> *smh@uk.ibm.com* <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/* <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* <http://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* <http://www.ogf.org/About/abt_policies.php>
-- 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
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
participants (2)
-
Mike Beckerle -
Steve Hanson