<br><font size=2 face="sans-serif"><b>Open Grid Forum: Data Format Description
Language Working Group</b></font>
<br>
<br><font size=2 face="sans-serif"><b>Weekly Working Group Conference Call</b></font>
<br><font size=2 face="sans-serif"><b>17:00 GMT, 21 Nov 2007</b></font>
<br>
<br><font size=2 face="sans-serif"><b>Attendees</b></font>
<br><font size=2 face="sans-serif">Mike Beckerle (IBM)</font>
<br><font size=2 face="sans-serif">Geoff Judd (IBM)</font>
<br><font size=2 face="sans-serif">Steve Hanson (IBM)</font>
<br><font size=2 face="sans-serif">Suman Kalia (IBM)</font>
<br><font size=2 face="sans-serif">Simon Parker (PolarLake)</font>
<br><font size=2 face="sans-serif">Ian Parkinson (IBM)</font>
<br>
<br>
<br><font size=2 face="sans-serif"><b>1. Introduction</b></font>
<br><font size=2 face="sans-serif">Mike would like, in this meeting, to
cover the hexBinary and base64Binary debate, and also to discuss the use
of 'any' wildcards with minOccurs and maxOccurs.</font>
<br>
<br><font size=2 face="sans-serif"><b>2. 'Any' wildcards with minOccurs
and maxOccurs</b></font>
<br><font size=2 face="sans-serif">The DFDL specification presently disallows
the use of minOccurs and maxOccurs on 'any' wildcards, in contrast to XML
schema. Simon stated that he sees no reason to forbid this, and that these
properties might be useful, for example when structures could be followed
by arbitrary extensions.</font>
<br>
<br><font size=2 face="sans-serif">Suman felt that the most common use
case would be minOccurs="0" and maxOccurs="1". Mike
wondered whether this would be useful within unordered groups, and thought
it would be a good way to model an 'all' group containing some known fields
and a number of unknown fields.</font>
<br>
<br><font size=2 face="sans-serif">Mike took an action item to investigate
this further.</font>
<br>
<br><font size=2 face="sans-serif"><b>3. hexBinary and base64Binary</b></font>
<br><font size=2 face="sans-serif">The working group has been discussing,
via email, the use of hexBinary and base64Binary types, along with 'enumeration'
and 'pattern' properties. Mike asked the group whether we should disallow
the 'enumeration' and 'pattern' properties on binary types (as they are
difficult to use, in particular with base64Binary), and whether we should
remove support for base64Binary (as it shares a value space with hexBinary,
and is therefore a synonym of hexBinary in DFDL).</font>
<br>
<br><font size=2 face="sans-serif">Simon felt that this distinction remained
a useful hint to any component emitting XML based on a DFDL infoset. He
also observed that base64Binary is more commonly used than hexBinary, and
is preferred. Mike argued that while base 64 might be preferred to hexadecimal
in terms of space, hexadecimal is more readable. Steve observed that hexBinary
is commonly used.</font>
<br>
<br><font size=2 face="sans-serif">While Mike felt that supporting fixed
and default binary values might lead to requiring support for patterns
and enumeration, the meeting agreed that there are use cases for default
and fixed values - for example, some file formats use "eyecatchers"
which are best expressed in hexadecimal. Mike pointed out that this could
be achieved usng a string type, but suggested allowing 'default' and 'fixed'
for hexBinary. Simon suggested that something similar would be necesssary
for base64Binary, as some values (such as passwords and identifiers) are
frequently expressed in base 64. </font>
<br>
<br><font size=2 face="sans-serif">Sandy Gao (IBM) has been asked to comment
on whether there are any use cases where patterns are used with hexBinary
of base64Binary.</font>
<br>
<br><font size=2 face="sans-serif">To conclude this discussion, Mike proposed
the following: to retain support for both base64Binary and hexBinary, with
identical content in DFDL; to allow both 'fixed' and 'default' for both
base64Binary and hexBinary, but (pending further information from Sandy)
to disallow 'pattern' and 'enum'.</font>
<br>
<br><font size=2 face="sans-serif">[Simon and Suman left the meeting]</font>
<br>
<br><font size=2 face="sans-serif"><b>4. Array Prefixes and Suffixes</b></font>
<br><font size=2 face="sans-serif">Mike asked whether the group was happy
with the omission of array prefixes and suffixes. We know how to add these
back should we ever need to, and there is a concern that including them
would lead to many more array properties being necessary. Steve was happy
with the present proposal.</font>
<br>
<br><font size=2 face="sans-serif"><b>5. Choice type and Length properties
on Choice</b></font>
<br><font size=2 face="sans-serif">Mike observed that there is a need to
distinguish between choice groups which are of constant length, and choice
groups where the length is determined by the relevent subelement. Where
the choice is unresolvable, it is not possible to have a choice of variable
length.</font>
<br>
<br><font size=2 face="sans-serif">Steve felt that as we are able to make
assertions, there would be very few cases where a choice is unresolvable.
Mike pointed out that in an unresolvable choice group, each arm would need
consistant enough syntax for a parser to be able to determine the end;
and that this could be modelled as arms with enough information to discriminate.
Geoff suggested that experience with IBM's MRM technology shows this to
be unusual.</font>
<br>
<br><font size=2 face="sans-serif">The meeting considered two options.
We could specify two properties, one to select between constant length
and variable length; and one to select between resolvable and unresolvable.
In this option, the combination variable-length/unresolvable would be disallowed.
In the second option, we would have a single property with three possible
values: constant length, variable length or unresolvable. The meeting agreed
upon the second option.</font>
<br>
<br><font size=2 face="sans-serif">When experimenting with the DFDL language
recently, Steve found specifying length on structures to be awkward. He
proposed removing 'lengthKind' on choice elements, and Mike added that
we would also wish to remove other associated properties such as 'intitator'
and 'terminator'. On reflection, the meeting decided to keep these properties,
noting that using these on a choice element is identical to wrapping the
choice element in a sequence element with the same properties.</font>
<br>
<br><font size=2 face="sans-serif"><b>6. Other business</b></font>
<br><font size=2 face="sans-serif">There has, internally within IBM, been
a discussion regarding length prefixes on strings. Mike will circulate
a proposal to the working group, to allow prefix formats to be described
through annotations on simpleType definitions.</font>
<br>
<br><font size=2 face="sans-serif"><b>Meeting closed, 17:55 GMT</b></font>
<br>
<br><font size=2 face="sans-serif"><br>
Ian Parkinson<br>
WebSphere ESB Development<br>
Mail Point 211, Hursley Park, Hursley, Winchester, SO21 2JN, UK</font><font size=3 face="sans-serif"><br>
</font>
<br><font size=3 face="sans-serif"><br>
</font>
<hr><font size=2 face="sans-serif"><br>
<i><br>
</i></font>
<p><font size=2 face="sans-serif"><i>Unless stated otherwise above:<br>
IBM United Kingdom Limited - Registered in England and Wales with number
741598. <br>
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU</i></font>
<p><font size=2 face="sans-serif"><br>
</font><font size=3 face="sans-serif"><br>
</font>
<br>
<br><font size=3 face="sans-serif"><br>
</font>