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" <mbeckerle.dfdl@gmail.com>
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" <mbeckerle.dfdl@gmail.com>
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