Do we have a section where this goes?

There are lots of implied implementation limits.

Maximum string length?
Maximum hexbinary length?
Maximum number of packed digits in various numbers.

Maximum length of a delimiter?
Maximum length of a fixed attribute?
Maximum length of a pattern regex expression?
Maximum length of a regular expression?

There's also limits on buffering of data for unparsing, etc.

There's also limits on lookahead/speculation. I.e., how far an implementation is willing to speculate forward.

etc.

For some types these are clear: e.g., binary xs:int is 32 bits max.

Do we need a numbered section on implementation specific limits.

On Tue, Sep 4, 2012 at 12:30 PM, Steve Hanson <smh@uk.ibm.com> wrote:
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

--
  dfdl-wg mailing list
  dfdl-wg@ogf.org
  https://www.ogf.org/mailman/listinfo/dfdl-wg



--
Mike Beckerle | OGF DFDL WG Co-Chair 
Tel:  781-330-0412