October 2024 - dfdl-wg - lists.ogf.org

Reminder for Agenda Topics for Workgroup call on 2024-06-13
by Mike Beckerle 05 May '25

05 May '25

Please send along any agenda topics you wish discussed on our next call which is next week. (If you are already aware you will be not attending, send that along as well) I do have one agenda topic to cover which is ISO document creation. I'll circulate a separate email introducing the topic.

1 4

Clarification needed on dfdl:decimalSigned
by Mike Beckerle 18 Nov '24

18 Nov '24

This property appears in exactly 3 places in the DFDL spec. * Section 13.5 where it is defined * Appendix G: 36.1 Parser - property precedence tables * Appendix G: 36.2 Unparser - property precedence tables. The definition in Section 13.5 says Indicates whether an xs:decimal element is signed. See 13.6.2 Converting logical numbers to/from text representation and 13.7.1 Converting Logical Numbers to/from Binary to see how this affects the presence of the sign in the data stream. 'yes' means that the xs:decimal element is signed 'no' means that the xs:decimal element is not signed Neither Section 13.6.2 nor 13.7.1 mention the decimalSigned property. We need to add language which clarifies this. I believe this is roughly what is needed: In Section 13.6.2, add this material at the start of the section: *The signed number types are byte, short, int, long, integer, float, double* *The unsigned number types have names beginning with "unsigned", as well as nonNegativeInteger.* *For type xs:decimal the decimal is considered signed if dfdl:decimalSigned="yes" and unsigned if dfdl:decimalSigned="no". * In Section 13.7.1 we need to add this: *When dfdl:binaryNumberRep="binary", then dfdl:decimalSigned controls whether the underlying representation is interpreted as a twos-complement signed binary integer or an unsigned binary integer. This value is then scaled using dfdl:binaryDecimalVirtualPoint to convert to/from the infoset value. * *When dfdl:binaryNumberRep is 'bcd', no sign is possible and the dfdl:decimalSigned property is ignored. * *When dfdl:binaryNumberRep is 'packed' a sign nibble is required and the dfdl:decimalSigned property is ignored.* *(rationale: packed but unsigned is the same as BCD)* *When dfdl:binaryNumberRep is "ibm4690Packed" the dfdl:decimalSigned property is used to determine if negative values are allowed, i.e., the packed digits may be preceded by a negative sign nibble.* *If dfdl:decimalSigned is "no" then no sign nibble is expected or allowed. * Mike Beckerle Apache Daffodil PMC | daffodil.apache.org OGF DFDL Workgroup Co-Chair | www.ogf.org/ogf/doku.php/standards/dfdl/dfdl Owl Cyber Defense | www.owlcyberdefense.com

2 5

clarification needed: prefixLengthType has min/max facets prefixIncludesPrefixLength="yes"
by Mike Beckerle 14 Nov '24

14 Nov '24

(Note: email sent to dfdl-wg at lists.ogf.org, not just ogf.org per prior practice.) Sometime back, in order to allow facets to sanity check prefix length values, we specified that if facets are expressed on a prefixLengthType they would always be checked and if they do not hold it is a processing error. This correction was part of the most recent GFD.240 However, we did not specify if the facet check is done on the prefix length value before or after it is adjusted when prefixIncludesPrefixLength="yes". So for example, suppose there is a single-byte prefix on a string and dfdl:prefixIncludesPrefixLength is "yes". Then the minimum well-formed value of the prefix is "1" which indicates a length 0 string with a single byte prefix. Suppose I want to add XSD facets to sanity check this prefix value: <simpleType name="prefix1Byte"> <restriction type="xs:unsignedByte"> <maxInclusive value="99"/> </restriction> </simpleType> So, if this type is used as the dfdl:prefixLengthType of a string with dfdl:lengthKind='prefixed', and dfdl:prefixIncludesPrefixLength="yes" then does the check for 99 measure the length of the string, or the value of the prefix, which is the length of the string plus one? My thought is that there is a quasi-element corresponding to this single byte prefix. That quasi-element's value is what is constrained by this maxInclusive facet. So I'm claiming the facet value 99 should be compared against the stored value in the prefix quasi-element, that is before any value adjustment is done for dfdl:prefixIncludesPrefixLength. Which is to say, suppose you switched to dfdl:lengthKind="explicit", and made an actual element of the single unsiged byte "prefix" field. Then the adjusting for the length of that prefix length would be done in the dfdl:length expression for the string, and the dfdl:outputValueCalc for the single byte prefix field. Which is to say that facets constraining the value of that one-byte element would apply to the value directly, not after any adjustment. I think lengthKind prefixed should work exactly the same as when a real length element and outputValueCalc are used. One should not have to adjust facets on the type of the length field when when it is the type of the length element, no should one have to adjust the facets if you convert and use lengthKind 'prefixed' with the dfdl:prefixLengthType, the facets should mean the same thing. Any thoughts/comments? Note: daffodil PR about this: https://github.com/apache/daffodil/pull/1334 JIRA Issue: https://issues.apache.org/jira/browse/DAFFODIL-2660

2 2

DFDL-WG Call/Meeting 2024-10-10 Agenda & Minutes
by Mike Beckerle 14 Oct '24

14 Oct '24

Due to mailing list bounces, this is going out after the fact. Apologies. Mail to dfdl-wg at lists.ogf.org appears to work properly. Here is the agenda and minutes for 2024-10-10 https://github.com/OpenGridForum/DFDL/blob/master/calls/2024/2024-10-10_DFD… Here is the minutes from 2024-09-12 Call: https://github.com/OpenGridForum/DFDL/blob/master/calls/2024/2024-09-12_DFD… Mike Beckerle OGF DFDL Workgroup Co-Chair | www.ogf.org/ogf/doku.php/standards/dfdl/dfdl Apache Daffodil PMC | daffodil.apache.org 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>

1 0