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. 3. Scoping Rules Steve suggested that DFDL could simplify its scoping rules, by treating all properties on elements, simpleTypes and sequences as if they were set with scope "hereOnly"; and giving scope applicability to properties on complexType definitions. This may, in particular, simplify DFDL tooling. This might require users to introduce an element and complexType definition into the middle of a structure purely for scoping purposes, however Mike suggested we allow scope-applicable properties to also be set on (named) model group definitions. This enables a model group definition and associated group reference to be used in the middle of a structure, instead of an element and complexType, which does not affect the infoset. Steve and Mike to think further on this subject, it sounds a promising simplification. 4. Other business 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. Meeting closed, 17:15 GMT Ian Parkinson WebSphere ESB Development Mail Point 211, Hursley Park, Hursley, Winchester, SO21 2JN, UK 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