Agreed on DFDL WG call 4th Sept to continue to support twos-complement decimal, integer or nonNegativeInteger, but to make the maximum implementation defined.

Regards

Steve Hanson
Architect, Data Format Description Language (DFDL)
Co-Chair, OGF DFDL Working Group
IBM SWG, Hursley, UK
smh@uk.ibm.com
tel:+44-1962-815848



From:        Steve Hanson/UK/IBM
To:        Mike Beckerle <mbeckerle.dfdl@gmail.com>
Cc:        dfdl-wg@ogf.org, dfdl-wg-bounces@ogf.org
Date:        15/08/2012 13:10
Subject:        Re: [DFDL-WG] proposed clarification/narrowing - no twos-complement decimal, integer or nonNegativeInteger

---

Mike

Having thought about this since our call yesterday, I am uncomfortable with the proposed narrowing. It means DFDL can not be guaranteed to handle the two's complement result of Java BigInteger.toByteArray().  I don't have a concrete use case of two's complement data > 8 bytes but I am sure that someone in the scientific community will need it at some point. Hence why it is allowed in the spec today.

If we do allow it, then we have to decide what happens during unparsing and lengthKind is 'prefixed'.   The equivalent of Table 16 for lengthKind 'pattern' is needed for lengthKind 'prefixed', as we discussed.  That would imply that the unparsing behaviour would be 'Minimum number of bytes to represent significant digits and sign'.  In other words, a two's complement binary integer is created that is just long enough to represent the infoset value.

Regards

Steve Hanson
Architect, Data Format Description Language (DFDL)
Co-Chair, OGF DFDL Working Group
IBM SWG, Hursley, UK
smh@uk.ibm.com
tel:+44-1962-815848




From:        Mike Beckerle <mbeckerle.dfdl@gmail.com>
To:        dfdl-wg@ogf.org
Date:        14/08/2012 19:33
Subject:        [DFDL-WG] proposed clarification/narrowing - no twos-complement decimal, integer or nonNegativeInteger
Sent by:        dfdl-wg-bounces@ogf.org

---

The spec is not clear on whether decimal, integer, and nonNegativeInteger support representation='binary' with binaryNumberRep='binary' (aka twos-complement). Since these types do not have any size limit, such a capability allows arbitrarily large twos-complement integers, or perhaps it would be an implementation defined limit.

I believe the right choice is that it should be disallowed. That is, only binaryNumberRep of 'bcd' or 'packed' should be allowed for these types. These types have always been about decimal-style representations to me.

This keeps twos-complement only for the types long, int, short, byte and their unsigned counterparts.

--
Mike Beckerle | OGF DFDL WG Co-Chair 
Tel:  781-330-0412
--
 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