[dfdl-wg] Telecon minutes 2006-04-12
Mike Beckerle
beckerle at us.ibm.com
Wed Apr 12 11:52:53 CDT 2006
DFDL WG call 2006-04-12
Bob McGrath
Geoff Judd
Mike Beckerle
Agenda
- arrays discussion
- issue of defaults
- outstanding property document discussion (deferred until a call with
more participants, particularly S. Hanson)
Arrays
We considered the 'string-with-all-lengths-first' example sent by MikeB.
It uses a @dfdl:index extension to our Xpath expression language. Email
traffic to the list asked for clarifications of why this is not just the
Xpath position() function. MikeB to post clarification.
We considered whether the @dfdl:index provides enough/too-much expressive
power. We agreed to create a 2d example. The parse/read direction seems
likely to work fine. The write/output direction seems less clear, but
we'll create a parse/read example first and then consider how/where to
hang the "inverse index calculations" on it.
Defaults
This is discussion of this issue raised by S. Hanson when he posted the
'properties' document on 3/23:
- The issue of defaults poses some questions. We have agreed that
hard-wired model defaults are not desirable as it means the absence of
a
property implies a behaviour. If we wish to change this behaviour then
we
are stuck because existing DFDL Schema then behave differently. So the
proposal in the scoping document is that all properties that are used
during a parse/serialise must have an explicit value defined somewhere
in
the DFDL Schema, typically in a dfdl:defineFormat annotation. However,
there are properties where we don't want a one-value-fits-all value,
but at
the same time do not want to specify a value on every element.
Example:
justification, where typically all strings are left justfied, and all
numbers are right justified. Example: calendarPattern, where the
patterns
for a date, dateTime, time, monthDay, etc are different. One approach
is to
duplicate the properties - so we would have textStringJustification,
textNumberJustification, and so on. You will see that this is what I
have
done in the document for justification. An alternative approach is to
have
one property, but to add an additional enum 'schema', which means
derive
the default from the logical type. You will see that this is what I
have
done for calendarPattern. So calendarPatternKind set to 'schema' for
xsd:date would yield "yyyy-MM-dd" and for xsd:time would yield
"hh:mm:ss.sss". Of course, 'schema' can be considered a form of
hard-wiring, so maybe we also need some properties that define what
these
defaults are (they'd only ever be set at dfdl:defineFormat level)? We
need
to decide which of these approaches is preferred, whether they both
make
sense, or if there is a better way.
We propose that the general approach here should be to split the
properties. That is, the textNumberJustification and
textStringJustification solution be used wherever this problem exists.
We couldn't see why the calendar stuff is sufficiently different. It seems
that there should be a datePattern, timePattern, dateTimePattern, and so
forth and these should be independent properties.
Another issue was identified which is exemplified by the separatorEncoding
property. It is possible for a separator to have a distinct character set
(obscure, but possible). However, in most cases it does not, and one would
like separatorEncoding to get its value from the regular encoding
property. However, if separatorEncoding was to have no binding at all in
the entire scope then this makes things quite confusing. Adding a binding
for separatorEncoding at an outer scope would affect lots of enclosed
separator behavior in unexpected ways.
Proposed solution: when properties are linked like this don't allow things
to be 'unbound', but rather require a binding which specifically states
the linkage between the properties. For example: in one of the include
files at top level there would be a defineFormat where separatorEncoding
is bound to a distinguished value which means "take the value for this
property from the encoding property". Scoping would then find this
distinguished value for separatorEncoding, and then start over from the
scope of the separator construct searching the scope/context for the
encoding property. This can be clarified in the next scoping draft and
should solve the problem. The syntactic device for specifying the value of
one property to come from another property is TBD.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/dfdl-wg/attachments/20060412/f9f3bf1d/attachment.htm
More information about the dfdl-wg
mailing list