Due to an issue with CutePDF truncating text, here is the agenda for today.

1. Spec issues from IBM
As implementation has progressed, a number of issues have been spotted in the DFDL 1.0 spec by the IBM implementation team.
List so far for resolution.

6.3. Bullet for logical value. State that the string must obey the lexical representation of the type.

6.3.1. Explicit statement of white space rules is missing. Just white space for a DFDL string literal property is an error. When a property can be a list of string literals, white space between values is collapsed.

7.7. What is the scope of a variable with respect to included/imported xsds? Can I refer from xsd A to a variable defined in parent xsd B?

9.2. Grammar. Does not allow for a prefix length itself having a prefixed length, so does not match property description (ie, the change to permit this is draft 045 omitted to update the grammar).

13. Be explicit on the DFDL literals allowed for text properties. See separate e-mail.

13.6. When textNumberRep is zoned, property description should state that base is assumed to be 10.

13.6. State that dfdl:ignoreCase not honoured by textStandardExponentCharacter, textStandardInfinityRep, textStandardNanRep as ICU does not offer that flexibility.

13.6 Allow multiple characters for textStandardExponentCharacter to handle reps like 1.23x10^4 as ICU allows that. Note that property name will have to change, eg, to textStandardExponent..

13.6. Change meaning of textNumberCheckPolicy 'lax' to align more closely with ICU:
"If ‘lax' and dfdl:textNumberRep is 'standard' then grouping separators are ignored, leading and trailing whitespace is ignored, leading zeros are ignored."

13.6. Disallow the use of empty string for textStandardExponentCharacter. State property must be set if the pattern contains an 'E'

13.6. Disallow the use of empty string for textStandardDecimalSeparator, State property must be set if the pattern contains a '.'

13.6 Disallow the use of empty string for textStandardGroupingSeparator, State property must be set if the pattern contains a ','

13.6. Allow decimal separator to be a List of DFDL String Literals or a DFDL expression. This allows modelling of EDIFACT where user can choose decimal separator in ISA header but '.' is also allowed.

13.6. When textNumberPadCharacter is '0' which it commonly is, a value of say '00000' will get trimmed to the empty string, whereas the intent would surely be to trim to '0'. Need a rule for this.

13.6.Should textStandardDecimalSeparator ignored when the logical type is not decimal/float/double?

13.6.1.1. Erroneously mentions sigDigits in reference to the BNF for textNumberPattern.

13.6.1.1. Formatting. Uses terms 'minimum/maximum integer/fraction digits' but does not define them.

13.9. Should state that textBooleanTrue/FalseRep properties are used after trimming when parsing, and before padding when unparsing. If lengthKind is explicit or implicit and either textPadKind or textTrimKind is none then the properties must have the same length else schema definition error.

13.16. Nil literal character. When representation is binary, the encoding property is not used, which implies that a nil value must only contain DFDL hex literals (%rXX;)

13.16. Clarify nilKind 'literalCharacter' and 'literalValue' and whether nil test is applied before or after trimming.

15. Using a discriminator to resolve each branch of a choice with a very large number of branches has a performance impact as each branch must be evaluated in turn. In cases where the name of the branch element is known or derivable in advance (ie, each discriminator expression is of the form {..\tag eq "elem1"} or similar) then consider adding a property to dfdl:choice that provides an expression that returns a QName, being the name of the branch element. Note: IBM MRM has something like this.

16.1. Revise entire section.

16.2. State it is a processing error if the stop value is missing when parsing.

2. Spec issues from Mike Beckerle
A number of issues have been spotted by Mike. Some have been resolved by action 139 below, but others remain.
See separate e-mail.

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 28/06/2011 14:46 -----

From:	"Mike Beckerle" <mbeckerle.dfdl@gmail.com>
To:	Steve Hanson/UK/IBM@IBMGB
Date:	28/06/2011 13:50
Subject:	RE: [DFDL-WG] OGF DFDL WG Call Agenda 2011-06-28

Steve,

When I download this agenda PDF file, it’s all cut off on the right edge of the page, making it hard to figure out what some of these line items are about.

Something is up with the way you converted this teamroom page to a pdf.

If this was paper, I’d suspect the metric vs. US paper size issue, but this is all bits…. J

…mikeb

From: dfdl-wg-bounces@ogf.org [mailto:dfdl-wg-bounces@ogf.org] On Behalf Of Steve Hanson
Sent: Monday, June 27, 2011 12:18 PM
To: dfdl-wg@ogf.org
Subject: [DFDL-WG] OGF DFDL WG Call Agenda 2011-06-28

Please find agenda for the above call on GridForge at:

http://forge.gridforum.org/sf/docman/do/downloadDocument/projects.dfdl-wg/docman.root.current_0.calls/doc16276/2

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