[dfdl-wg] Telecon minutes 2006-04-12

Mon Apr 17 15:25:31 CDT 2006

"Where properties are specific to a physical representation, the property
name may choose to reflect this. Where properties are related to a specific
logical type ‘group’ (defined below), the property name may choose to
reflect this."

Just following this rule. All the other properties in the calendar scheme
have 'calendar' as prefix.

Regards, Steve

Steve Hanson
WebSphere Message Brokers,
IBM United Kingdom Ltd, Hursley, UK
Internet: smh at uk.ibm.com
Phone (+44)/(0) 1962-815848

             Mike Beckerle                                                 
             <beckerle at us.ibm.                                             
             com>                                                       To 
                                       Steve Hanson/UK/IBM at IBMGB           
             14/04/2006 02:04                                           cc 
                                       dfdl-wg at ggf.org,                    
                                       owner-dfdl-wg at ggf.org               
                                                                   Subject 
                                       Re: [dfdl-wg] Telecon minutes       
                                       2006-04-12                          

I'm curious why these names all have to have calendar on the front. Is that
strictly speaking necessary? I know it's consistent with the taxonomy you
have set out, but it's not clear to me that all the date&time words aren't
sufficiently unambiguous as to identify the category clearly.

...mikeb

Mike Beckerle
STSM, Architect, Scalable Computing
IBM Software Group
Information Integration Solutions
Westborough, MA 01581
voice and FAX 508-599-7148
home/mobile office 508-915-4795

 Steve Hanson <smh at uk.ibm.com>                                             
 Sent by: owner-dfdl-wg at ggf.org                                            

                                                                        To 
 04/13/2006 10:36 AM                             dfdl-wg at ggf.org           
                                                                        cc 

                                                                   Subject 
                                                 Re: [dfdl-wg] Telecon     
                                                 minutes 2006-04-12        

If my understanding is correct, you are proposing to replace the single
calendarPattern property within a calendarScheme by set of pattern
properties, one for each of the built-in XML Schema date/time logical
types. I'm ok with that.  So we would have the following pattern
properties, and the property to use for a given element is governed by the
schema type.

calendarDateTimePattern
calendarDatePattern
calendarTimePattern
calendarYearMonthPattern
calendarYearPattern
calendarMonthPattern
calendarMonthDayPattern
calendarDayPattern

I like the proposal for separatorEncoding too.

Regards, Steve

Steve Hanson
WebSphere Message Brokers,
IBM United Kingdom Ltd, Hursley, UK
Internet: smh at uk.ibm.com
Phone (+44)/(0) 1962-815848

            Mike Beckerle
            <beckerle at us.ibm.
            com>                                                       To
            Sent by:                  dfdl-wg at ggf.org
            owner-dfdl-wg at ggf                                          cc
            .org
                                                                  Subject
                                      [dfdl-wg] Telecon minutes
            12/04/2006 17:52          2006-04-12

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.