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
