Another corner case is xs:decimal dfdl:decimalSigned="yes" dfdl:binaryNumberRep="bcd".As I understand it BCD is fundamentally unsigned. Is this an SDE? SDW? or is it just that the signed decimal number if negative will cause a Parse Error?On Tue, Oct 29, 2024 at 4:18 PM Mike Beckerle <mbeckerle@apache.org> wrote:What about the corner case of xs:decimal, dfdl:decimalSigned="no" dfdl:binaryNumberRep="packed" ?I think packed always has a sign nibble. In this case is it just a parse error if the data has a negative sign nibble?On Tue, Oct 29, 2024 at 8:50 AM Steve Hanson <smhdfdl@gmail.com> wrote:Hi MikeI don't think that is necessary. The texts in 13.6.2 and 13.7.1 use the phrases "Signed number" and "Unsigned number". This means whether the logical type is signed or not. That is always known from the type itself, except for xs:decimal where we need dfdl:decimalSigned. I think all we need to change is this sentence in the definition of dfdl:decimalSigned, from ...Indicates whether an xs:decimal element is signed.... to ...Indicates whether an xs:decimal element is a signed number or an unsigned number.I also think it would be useful for Liam to have a look at the IBM DFDL code and see where dfdl:decimalSigned is actually used.While looking at the sections on property precedence, I noticed two uses of a property name I did not recognise - packedDecimalSignCodes. They both should be binaryPackedSignCodes. Amazing how blatant errors like this still exist after all this time.RegardsSteveOn Mon, Oct 28, 2024 at 9:30 PM Mike Beckerle <mbeckerle@apache.org> wrote:--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 saysIndicates 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 signedNeither 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, doubleThe 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.
dfdl-wg mailing list -- dfdl-wg@lists.ogf.org
To unsubscribe send an email to dfdl-wg-leave@lists.ogf.org
%(web_page_url)slistinfo/%(_internal_name)s