[DFDL-WG] DFDL: Minutes from OGF WG call, 02 Apr 2008

[Ian W Parkinson]

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





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/dfdl-wg/attachments/20080403/283f39be/attachment.html