"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@uk.ibm.com Phone (+44)/(0) 1962-815848 Mike Beckerle <beckerle@us.ibm. com> To Steve Hanson/UK/IBM@IBMGB 14/04/2006 02:04 cc dfdl-wg@ggf.org, owner-dfdl-wg@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@uk.ibm.com> Sent by: owner-dfdl-wg@ggf.org To 04/13/2006 10:36 AM dfdl-wg@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@uk.ibm.com Phone (+44)/(0) 1962-815848 Mike Beckerle <beckerle@us.ibm. com> To Sent by: dfdl-wg@ggf.org owner-dfdl-wg@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.