[DFDL-WG] proposed clarification/narrowing - no twos-complement decimal, integer or nonNegativeInteger

[Steve Hanson]

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 at uk.ibm.com
tel:+44-1962-815848



From:   Steve Hanson/UK/IBM
To:     Mike Beckerle <mbeckerle.dfdl at gmail.com>
Cc:     dfdl-wg at ogf.org, dfdl-wg-bounces at 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 at uk.ibm.com
tel:+44-1962-815848




From:   Mike Beckerle <mbeckerle.dfdl at gmail.com>
To:     dfdl-wg at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20120904/9d1ae859/attachment.html>