For discussion on today's call...
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
----- Forwarded by Steve Hanson/UK/IBM on 20/09/2011 11:00 -----
From:
Steve Hanson/UK/IBM
To:
"Mike Beckerle"
Cc:
Richard Schofield/UK/IBM@IBMGB, Tim Kimber/UK/IBM@IBMGB
Date:
25/08/2011 13:48
Subject:
RE: DFDL WG action 143: Proposed resolution
Although this action was closed on 5th July WG call, I did find this one
extra issue about WSP and textStandardZeroRep and we did not reach a
conclusion. I will add it to WG call agenda.
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"
To:
Tim Kimber/UK/IBM@IBMGB, Steve Hanson/UK/IBM@IBMGB
Cc:
Richard Schofield/UK/IBM@IBMGB
Date:
05/07/2011 21:49
Subject:
RE: DFDL WG action 143: Proposed resolution
Well…..
The use case I have is from ancient mainframe style data. Numbers that
are all zero are suppressed and all blanks are output instead of anything
with zeros in it, or even a single 0 character. This is for data that was
both data and “report” simultaneously, i.e., people looked at it.
…mikeb
From: Tim Kimber [mailto:KIMBERT@uk.ibm.com]
Sent: Tuesday, July 05, 2011 3:00 PM
To: Steve Hanson
Cc: mbeckerle.dfdl@gmail.com; Richard Schofield
Subject: Re: DFDL WG action 143: Proposed resolution
We might want to bear this scenario in mind:
Field 'integerA' has explicit length of 5 and textNumberZeroRep='%WSP*;'.
The next field is a string which happens to start with some white space.
The parser must be careful to ensure that the matching of the %WSP;
against the data stream does not walk on into the following field's data.
On balance, I would prefer an alternative solution based on either
defaulting or nil handling:
a) We could define 'empty' in terms of the trimmed value when padKind !=
"none". That would allow this to be handled by setting the pad character
to space and xs:default to zero.
b) Without any change to the specification, the user could
- set nilLiteralCharacter="%SP;" and xs:nillable="true" or
- set nilLiteralValue of %ES; , set textStringPadCharacter="'%SP;", set
xs:nillable="true"
Either of these would result in a nil in the infoset. This may not be the
exact infoset that the user wants, but DFDL ( esp. DFDL 1.0 ) does not
guarantee that DFDL emits the exact infoset that you want.
In other words, I don't think the spaces are really a representation of
the value zero. They are padding or filling that the modeller wants to
treat as zero.
regards,
Tim Kimber, Common Transformation Team,
Hursley, UK
Internet: kimbert@uk.ibm.com
Tel. 01962-816742
Internal tel. 246742
From: Steve Hanson/UK/IBM
To: mbeckerle.dfdl@gmail.com
Cc: Tim Kimber/UK/IBM@IBMGB
Date: 05/07/2011 18:49
Subject: DFDL WG action 143: Proposed resolution
Mike
I was about to mail this out but noticed that textStandardZeroRep was
included in the list, and was being prohibited from using WSPx entitities.
This would not conveniently allow the scenario you mentioned on the call
today where all spaces was allowed to represent zero.
I can remove textStandardZeroRep from the list, and leave it as per spec
if you prefer. Tim - do you have a problem with that?
Regards
Steve
--------------------------------------------------------------
Following is the resolution from action 143
An errata document accompaniment to the DFDL 1.0 specification is under
production and this will be added to it.
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
----- Forwarded by Steve Hanson/UK/IBM on 05/07/2011 18:33 -----
Clarification to the allowable content that is allowed in some of the DFDL
properties that are defined as type 'DFDL String Literal'. The properties
below do not need the full power of DFDL String Literal.
Properties escapeCharacter and escapeEscapeCharacter
Property value must resolve to a single character
DFDL character entities are allowed
The raw byte entity ( %#r ) is not allowed
DFDL Character classes ( NL, WSP, WSP+, WSP*, ES ) are not allowed
Properties escapeBlockStart and escapeBlockEnd
DFDL character entities are allowed
The raw byte entity ( %#r ) is not allowed
DFDL Character classes ( NL, WSP, WSP+, WSP*, ES ) are not allowed
Properties textStringPadCharacter, textNumberPadCharacter,
textBooleanPadCharacter and textCalendarPadCharacter
Property value must resolve to a single character or a single byte value
DFDL character entities are allowed
The raw byte entity ( %#r ) is allowed subject to the restrictions already
documented for these properties
DFDL Character classes ( NL, WSP, WSP+, WSP*, ES ) are not allowed
Properties textStandardDecimalSeparator and textStandardGroupingSeparator
Property value must resolve to a single character
DFDL character entities are allowed
The raw byte entity ( %#r ) is not allowed
DFDL Character classes ( NL, WSP, WSP+, WSP*, ES ) are not allowed
Properties textStandardInfinityRep, textStandardNanRep,
textStandardZeroRep
DFDL character entities are allowed
The raw byte entity ( %#r ) is not allowed
DFDL Character classes ( NL, WSP, WSP+, WSP*, ES ) are not allowed
Properties textBooleanTrueRep and textBooleanFalseRep
DFDL character entities are allowed
The raw byte entity ( %#r ) is not allowed
DFDL Character classes ( NL, WSP, WSP+, WSP*, ES ) are not allowed
Property nilValue
DFDL character entities are allowed
The raw byte entity ( %#r ) is allowed
DFDL Character classes ( NL, WSP, WSP+, WSP*, ES ) are allowed
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
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
