RE: More tweaks on time related datatypes and minor editorial

Whatever is decided, it must be thoroughly defined and have sufficient examples,
but I disagree with Curt on some of the others points.

Splitting time periods to separate attributes would make parsing and validating
a little tougher I think.  Having to locate and parse 2 attrbiutes would require
them to be handled differently than other attributes which have only one
"value".  You could leave it up to the application to combine the 'start',
'end', and 'duration' fields but then the validator wouldn't be able to do any
constraint checking.

Time zone qualifiers are fairly simple to parse and are quite useful even in
durations. I would leave them as currently defined.

george


-----Original Message-----
From: Curt Arnold [mailto:carnold@houston.rr.com]
Sent: Saturday, January 22, 2000 1:13 AM
To: www-xml-schema-comments@w3.org
Cc: gtj@peakin.com
Subject: More tweaks on time related datatypes and minor editorial


This is somewhat related to George Joseph's previous post.

1) First, my interpretation of this statement:

   Time periods, i.e. specific durations of time, can be represented by
supplying two items of information:
   a start instant and a duration or a start instant and an end instant or
an end instant and a duration.

Is that a time period, could be represented by the combination of two
attributes (or two element content) where one is a timeInstant and the other
a timeDuration or timeInstant, for example:

<quietPeriod start="1999-11-05T12:00:00Z" end="1999-12-17T00:00:00Z"/>
or
<quitePeriod start="1999-11-05T12:00:00Z" duration="1M12D"/>

George's interpretation is this is an allowance for ISO8601's time period
formats such as

<quietPeriod start="1999-11-05T12:00:00Z/1999-12-17T00:00:00Z"/>

I believe that my interpretation is consistent with the preceding discussion
of the lexical representation, but please clarify for George and possibly
make the quoted paragraph less ambiguous.

2) Comparisons of timeDurations

As discussed in previous messages, evaluation of min and max constraints on
timeDuration can be problematic since the month and year terms are imprecise
(months being between 28-31 days and years being 365 or 366 days).  Based on
a suggestion George made on the Xerces list (and attributed to the ISO 8601
spec, but I can't find any mention of it). I would recommend that for
evaluation of min and max constraints on timeDurations (and only for that
comparision) that fixed unambiguous durations be specified for year and
date.  Somebody can check my math, but for a 400 year cycle, the average
length of a year is 31556952 seconds.  One twelveth (a month) of this is
2629746 seconds.  These values would result in P1Y == P12M, P366D > P1Y >
P365D, P31D > P1M > P30D.  I think this is reasonable behavior and resolves
a sticky issue.  However, the recommendation must explicitly describe how
this comparision should be performed.


3) Elimination of time zone offsets on timeInstant and time types.

Currently, timeInstant and time allow either a 'Z' to indicate Universal
Coordinated Time or a time zone offset from UTC in the format
('+'|'-')hh:mm.  It substantially complicates comparsion of times when the
times have different time zone offsets.  When the time zone offset are the
same, comparisions can be made lexically.  The time zone offset is either a
hint at the time zone of some action or observer or an attempt to make the
format more presentable to someone reading the XML file.  If the first, then
that information should be made explicit.  If the second, then that violates
the spirit of XML to keep data and presentation separate and does so at the
cost of complexity and possibly performance degradation.

My suggestion is that only Z be supported for timeInstant and time.  This
would allow these types to lexically compared.  If a time zone offset for a
display or a particular location needs to be specified, it could be
specified with an additional attribute (or element) with a timeDuration
datatype.

<Flight number="1234" departCode="IAH" departTime="14:23:00Z"
departTimezone="-PT6H" arriveCode="DTW" arriveTime="16:54:00Z"
arriveTimezone="-PT5H"/>


dates would still need to allow a time zone qualifier.  I would suggest that
the time zone qualifer be ignored in the evaluation of min and max
constraints on dates.

Received on Sunday, 23 January 2000 12:24:25 UTC