[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: XML Schema Datatype: unanswered questions.
- From: "Arnold, Curt" <Curt.Arnold@hyprotech.com>
- To: "'firstname.lastname@example.org'" <email@example.com>
- Date: Tue, 03 Apr 2001 16:58:16 -0600
I'm going to admit that I haven't had the chance to read the latest schema draft, but I need to real soon now. I do think that Kohsuke Kawaguchi has some legitimate comments and I'll try to add my
two cents as a fellow outsider.
>> last moment. Numbers and time/dates both have been very difficult to get
>> right (indeed, we basically gave up on producing an acceptable type
>> heirarchy for dates and times for XML Schemas 1.0).
> It seems to me that WG gave up producing acceptable types (not only
>hierarchy but types themselves) for dates and times.
I'm glad to see recurringDate and the like disappear, it definitely strained the conceptual model of datatypes at least to and past the breaking point. You had an "atomic" datatypes with two parts (I
guess those were then subatomic types) and you had derived datatypes with radically different lexical representations from the base type.
That said, I concur that you have legitimate comments on the date and time types.
This posting concerned the use of min and max constraints on a time datatype when the interval contained 00:00:00Z and/or 24:00:00Z. The example was trying to create a datatype representing Japanese
<!-- our business hours -->
<minInclusive value="08:00:00+09:00" />
<maxInclusive value="17:00:00+09:00" />
Converting this to UTC (the canonical form) would result in:
<!-- our business hours -->
<minInclusive value="17:00:00Z" />
<maxInclusive value="02:00:00Z" />
resulting in the violation of the constraint that minInclusive must be less than maxInclusive.
However, this problem is not just an artifact of the time zone qualifier. It is a totally legitimate to say that evening drinking hours in London are between 5 pm and 2 am.
The problem is that time, gMonthDay, gMonth and gDay are cyclical and the rules for minInclusive and maxExclusive do not account for that. It would be equally legitimate to create a constraint that a
gMonthDay has to fall between Christmas and New Years' Day, that a Winter month has to fall between December and March and that a bill must be paid between the 25th and the 2nd.
I would recommend something like the following: drop the restriction that mins must be less than maxes for cyclical types. You could require that both min and max constraints be specified (or both be
omitted) (you could default the mins to the start of the cycle (00:00:00, 01-Jan, Jan, 1st) and the maxs to the end but then it becomes messy to guess whether a time zone qualifier should be
provided). If min < max then values between min and max are acceptible, min == max is prohibited and if min > max then values between min and cycle end and cycle begin and max are acceptible.
In mapping to relational databases or other type systems, then the min/max constraint could be split into OR'd conditionals if min > max.
Definitely seems like a legitimate problem. I would suspect the truncation effect of that clause would cause problems (or at least counterinititive results).
>The following three are very simple mistakes. A WG member promised me a
>correction. But the truth is the same errors still remain in PR spec.
>Those two are also related to date/time types. And again, no answer has
> Actually, I've posted more than 20 comments to firstname.lastname@example.org
>but more than half are unanswered at all. It sure is a good way to
>discourage people from sending comments.
> I'm not familiar with W3C process, but is WG allowed to ignore public
>reviews? I understand that the WG is very busy and obviously it is
>impossible to answer *all* of the comments, but how can they ignore
>comments like first two ?
I definitely think the Last Call cycle was done better than the Candidate Recommendation cycle to allow feedback from "outsiders". In the Last Call cycle there was a publically accessible issues list
where you could see what issues the WG thought were open and their resolutions. If the thought that a significant issue had been overlooked, you could lobby for it to be added to the issues list and
you were able to see parts of the internal debate within the WG.
In the Candidate Recommendation phase, despite repeated "suggestions" that at least the issues list be made publically available, this process was not visible except a final issue closure request if
you had an issue that made the internal WG issues list.