Open Grid Forum: Data Format Description Language Working Group

Weekly Working Group Conference Call
16:00 GMT, 2 Apr 2008


Attendees
Mike Beckerle (Oco)
Steve Hanson (IBM)
Ian Parkinson (IBM)
Alan Powell (IBM)

1. Calculated Values
Mike has distributed a revised calculated values section. Alan has replied with some comments which will be incorporated.

2. Nil, Defaults and Optional Elements
The working group reviewed Alan's revised treatment of nil, defaults and optional elements, based on some discussions which took place within IBM. The following points were touched upon:

• The "nullKind" property has a possible value "xpath", this has changed to be "nullIndicator"
• When "nullIndicator" used, the associated descriptions of "nullIndicatorPath" and "nullIndicatorIndex" are not clear, and may not describe the intended use of these properties. They currently allow the null indicator to be any data type, and the null indicator value is compared against the "nullValues" list. The group opted to change this so that the null indicator must be xs:boolean, logical value "true" meaning that the field is null (no comparison against "nullValues").  Also it was decided to limit the "nullIndicatorPath" to a path XPath, and not a full expression, to allow inversion of the XPath on output.
• When "nullIndicator" used and unparsing, it is not obvious what bytes to write into a nil field - in principle, the minimum length of the field is filled with either fillByte or padChar. However, if an optional variable length field may be zero bytes long, we may not be able to distinguish between fields which are present but nil, and fields which are not present. Just as we disallow strings with a default value to have minLength="0", we could disallow potentially zero-length nillable elements.
• The specification should follow the convention established by XML Schema, and refer to 'nil' rather than 'null'.
• The "useNullValueForDefault" property presently only has meaning during unparse, and Steve felt this was asymmetric with parsing, where to get a missing element to have the value NULL in the infoset, you use an empty string as a null value. Mike observed an important symmetry in the ordinary case where the element is present but nil in either the source document during parse, or the source InfoSet during unparse, in that the nullValues list is used in both cases. After discussion, the group agreed that the property should be renamed to "useNilForDefault" and honoured for both parse and unparse.
• The format of the "nullValues" list is awkward, but it does allow all possible values to be represented. Alan will consider adding an 'empty string' entity to the set of defined DFDL entities.

• Simplification: Steve asked Mike to consider whether we could remove the occursSeparator property. If an array has a separator, this can be achieved by wrapping the array in a sequence, which we already have to do if the array (as a whole) has an initiator or terminator. This provides a consistent rule - array has markup, array needs sequence wrapper. Mike agreed this was a desired simplification. Steve to write up proposal.
• Simplification: Steve asked Mike whether it would be possible to remove the occursStopValue property as it could be considered a terminator of an enclosing group. Mike pointed out that if the stop value is literal value that's fine, but not when it's logical value. Agreed that we could remove occursStopKind and always treat occursStopValue as logical value. Steve to write up proposal.
• Steve has distributed a new revision of the Decimal supplement, and is looking for feedback.
• Next weeks meeting should include a discussion of the Decimal supplement, and of Mike's work on calculated values.

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