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 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