[DFDL-WG] Fw: DFDL WG action 143: Proposed resolution

Steve Hanson smh at uk.ibm.com
Tue Sep 20 05:06:10 CDT 2011


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 at 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 at gmail.com>
Cc:
Richard Schofield/UK/IBM at IBMGB, Tim Kimber/UK/IBM at 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 at uk.ibm.com
tel:+44-1962-815848



From:
"Mike Beckerle" <mbeckerle.dfdl at gmail.com>
To:
Tim Kimber/UK/IBM at IBMGB, Steve Hanson/UK/IBM at IBMGB
Cc:
Richard Schofield/UK/IBM at 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 at uk.ibm.com] 
Sent: Tuesday, July 05, 2011 3:00 PM
To: Steve Hanson
Cc: mbeckerle.dfdl at 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 at uk.ibm.com
Tel. 01962-816742 
Internal tel. 246742




From:        Steve Hanson/UK/IBM 
To:        mbeckerle.dfdl at gmail.com 
Cc:        Tim Kimber/UK/IBM at 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 at 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 at 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






-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/dfdl-wg/attachments/20110920/b8a83530/attachment-0001.html 


More information about the dfdl-wg mailing list