Secondly, given the above decision,
we can complete action 020. On parse, if the physical data can not be handled
by the logical type, it is a processing error. On unparsing, data must
conform to the infoset type, by definition.
Logical type | textNumberRepresentation=
text (4) | textNumberRepresentation=
zoned (2) (6) | binaryNumberRepresentation=
packed (5) | binaryNumberRepresentation=
bcd (1) | binaryNumberRepresentation=
binary |
Signed (decimal, integer, and user restrictions thereof) | Parse: OK
Unparse: OK | Parse: Unpunched data => +ve
Unparse: Data always punched with sign | Parse: Unsigned nibble =>
+ve
Unparse: Data signed as per +ve/-ve nibble specifiers, unsigned nibble specifier never used | Parse: Data always +ve
Unparse: -ve data is processing error | N/A |
Signed (long, int, short, byte, and user restrictions thereof) | Ditto | Ditto | Ditto | Ditto | Parse: Data assumed 2's complement
binary
Unparse: Data output as 2's complement binary |
Unsigned (unsigned long, unsigned int,
unsigned short, unsigned byte, and user restrictions thereof)
(3) | Parse: +ve data => OK, -ve
data is processing error
Unparse: Data output according to pattern | Parse: +ve punched data =>
OK, -ve data is processing error
Unparse: Data never punched with sign | Parse: +ve nibble & unsigned
nibble => OK, -ve nibble is processing error
Unparse: Unsigned nibble specifier always used | Parse: OK
Unparse: OK | Parse: Data assumed unsigned
binary
Unparse: Data output as unsigned binary |
Steve Hanson/UK/IBM
13/05/2009 13:25 |
|
Steve Hanson/UK/IBM
29/04/2009 15:54 |
|
Steve Hanson/UK/IBM
27/04/2009 13:42 |
|
This says to me that the DFDL parser
must have done enough validation to ascertain that the value matched the
underlying built-in type. For example, I have a user-defined simple type
that adds a max/min range of +100-+200 to an xs:unsignedInt. If the input
data has value 99, the value will be accepted into the infoset, but will
not validate if validation is switched on. If the input data is a packed
decimal with value -1, the value will not be accepted into the infoset.
Given that xs:unsignedInt is itself just a range restriction of xs:integer
(via xs:nonNegativeInteger), this seems a bit arbitrary.
Dave - given your action item looking
at DFDL Infoset versus XDM, I'd be interested in your opinion here.
Regards
Steve Hanson
Programming Model Architect
WebSphere Message Brokers
Hursley, UK
Internet: smh@uk.ibm.com
Phone (+44)/(0) 1962-815848
Alan Powell/UK/IBM
24/04/2009 15:13 |
|
From: | Steve Hanson/UK/IBM |
To: | mbeckerle@oco-inc.com, Alan Powell/UK/IBM, dglick@dracorp.com |
Date: | 23/04/2009 12:50 |
Subject: | Action 020 completion |
Logical type | textNumberRepresentation=
text (4) | textNumberRepresentation=
zoned (2) (6) | binaryNumberRepresentation=
packed (5) | binaryNumberRepresentation=
bcd (1) | binaryNumberRepresentation=
binary |
Signed (decimal, integer) | Parse: OK
Unparse: OK | Parse: Unsigned data => +ve
Unparse: Data always punched with sign | Parse: Unsigned data => +ve
Unparse: Data signed as per +ve/-ve nibble specifiers, unsigned nibble specifier never used | Parse: Data always +ve
Unparse: -ve data is error | N/A |
Signed (long, int, short, byte) | Ditto | Ditto | Ditto | Ditto | Parse: Data assumed 2's complement
binary
Unparse: Data output as 2's complement binary |
Unsigned (unsigned long, unsigned int,
unsigned short, unsigned byte)
(3) | Parse: -ve data is error
Unparse: -ve data is error | Parse: +ve data => OK, -ve
data is error
Unparse: Sign never punched, -ve data is error | Parse: +ve data => OK, -ve
data is error
Unparse: Unsigned nibble specifier always used, -ve data is error | Parse: OK
Unparse: -ve data is error | Parse: Data assumed unsigned
binary
Unparse: Data output as unsigned binary |
Steve Hanson/UK/IBM
18/02/2009 16:55 |
|
Steve Hanson/UK/IBM
12/02/2009 13:18 |
|
"Mike Beckerle"
<mbeckerle.dfdl@gmail.com>
12/02/2009 12:51
|
|
Mike Beckerle | OGF DFDL
WG Co-Chair | CTO | Oco, Inc.
Tel: 781-810-2100 | 504 Totten Pond Road, Waltham MA 02451
| mbeckerle.dfdl@gmail.com
Steve Hanson/UK/IBM
28/01/2009 13:54 |
|
020
| SH: Resolve packedDecimalSignCodes
behaviour depends on NumberCheckPolicy 22/10: No progress 10/12: added how to decide to overpunch and sign position |
binaryNumberCheckPolicy | Enum
Values are “strict” and “lax”. Indicates how lenient to be when parsing binary numbers. If ‘lax” then the parser tolerates all valid alternatives where such alternatives exist. Specifically, for binaryNumberRepresentation = 'packed' the sign nibble for positive, negative, unsigned and zero is allowed to be any of the valid respective values. On unparsing, the specified value is always used. |
Also suggest changing some of the other property names in 15.4:
"decimalVirtualPoint" -> "binaryDecimalVirtualPoint"
"packedDecimalSignCodes" -> "binaryPackedSignCodes"
And changing binaryNumberRepresentation enumeration:
"BCD" -> "bcd"
b) Zoned decimals: How to decide to overpunch and sign position
Spec assumes that overpunching of the rightmost character always takes
place. IBM architecture allows no overpunching (ie, Fx instead of Cx/Dx)
- this is supported by IBM MRM & WTX parsers. Additionally IBM MRM
parser allows separate sign byte, and sign byte on left. Let's deal with
these separately:
i) No overpunching.
The IBM architecture allows the rightmost byte to have a zone (Fx) or a
sign (Cx/Dx) as the left nibble. I don't see why we can't base what to
expect when parsing, and output when unparsing, on the logical xsd type.
- If it is an unsigned type then DFDL expects the rightmost byte to have
a zone nibble when parsing, and outputs a zone nibble when unparsing.
- If it is a signed type then DFDL expects it to have a sign nibble when
parsing, and outputs a sign nibble when unparsing.
For analogy with DFDL packed decimals, it seems at first glance that we
should also extend the numberCheckPolicy 'lax' setting to treat a zone
nibble as a +ve sign nibble for a signed type. However, IBM iSeries always
outputs Fx to mean +ve but accepts both Fx & Cx on input. It is perhaps
better therefore that DFDL always tolerates Fx when parsing a signed zoned
decimal, otherwise iSeries users would always have to set numberCheckPolicy
to 'lax', which might have other implications in the future.
ii) Separate sign byte.
I don't believe the IBM architecture allows this. I don't think DFDL needs
to support it. MRM has this, but I think it's because early on MRM did
not explicitly support text decimals as such, just COBOL variations, and
it was easier just to call them all zoned.
iii) Sign byte on left.
I don't believe the IBM architecture allows this. I don't think DFDL needs
to support it. MRM
has this, but for the same reason as ii)
Conclusion: No new DFDL properties needed, but words need adding to explain
zoned parse/unparse behaviour better.
Also suggest changing property names:
"zonedDecimalSignStyle" -> "numberZonedSignStyle"
"zeroNumberRep" -> "numberZeroRep"
Should also make clear that any explicit negative pattern in numberPattern
will be ignored if the xsd type is unsigned. (We could make this an error
but it precludes creation of a textNumberFormat that works with both signed
and unsigned types, plus pattern "##0.0" implictly is equivalent
to "##0.0;(##0.0)" ).
Regards
Steve Hanson
Programming Model Architect
WebSphere Message Brokers
Hursley, UK
Internet: smh@uk.ibm.com
Phone (+44)/(0) 1962-815848
Alan Powell/UK/IBM@IBMGB
Sent by: dfdl-wg-bounces@ogf.org 23/01/2009 13:36 |
|
Actions raised at this meeting
No
| Action |
031
| |
Current Actions:
No
| Action |
012
| AP/SH: Update decimalCalendarScheme
10/9: Not allocated yet 17/9: No update 24/9: Add calendar binary formats to actions 22/10: No progress 16/1: proposal distributed and discussed. Will be redistributed 21/1: add locale, |
020
| SH: Resolve packedDecimalSignCodes
behaviour depends on NumberCheckPolicy 22/10: No progress 10/12: added how to decide to overpunch and sign position |
023
| MB: Review Schema 1.1 |
024
| String XML type |
025
| Escape schemes 21/1: discussed requirements |
026
| SH: Envelopes and Payloads |
027
| Property precedence tables |
028
| Variable markup |
029
| valueCalc (output length calculation) |
030
| AP: confirm with WTX that can drop duration
21/6: WTX confirm that they do not have a duration type so do not need it in dfdl. Will drop from spec. Closed |
Closed actions:
030
| AP: confirm with WTX that can drop
duration 21/6: WTX confirm that they do not have a duration type so do not need it in dfdl. Will drop from spec. Closed |
034 Work items:
No
| Item | |
001
| String XML type (Ian P) - Apr 30, 2008 | |
002
| Escape schemes (Ian P) - Apr 30, 2008 | |
003
| Variables - ??, 2008 (Mike) | |
005
| Improvements on property descriptions - ??, 2008 (All - split TBD) | |
006
| Envelopes and Payloads (Steve) - Apr 30, 2008 | |
007
| (from draft 32) valueCalc (Mike) - ??, 2008 | mostly complete |
008
| (from draft 32) Property precedence for writing (Steve) - | under review |
009
| (from draft 32) Variable markup (Steve) - Mar 31, 2008 | proposal needs writing up |
010
| (from draft 32) Assertions, discriminators and choice, including discussion of timing option (Suman) - Mar 31, 2008 * in progress * | |
011
| (from draft 32) How speculative parsing works (combining choice and variable-occurence - currently these are separate) ??, 2008 (IBM) | in progress |
012
| (from draft 32) Reordering the properties discussion: move representation earlier, improve flow of topics ??, 2008 (Alan) * not started * | |
025
| Augmented infoset and unparsing (Alan) | added but needs work |
complete - specification updated
Alan Powell
MP 211, IBM UK Labs, Hursley, Winchester, SO21 2JN, England
Notes Id: Alan Powell/UK/IBM email: alan_powell@uk.ibm.com
Tel: +44 (0)1962 815073
Fax: +44 (0)1962 816898
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
http://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
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
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
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