RE: More tweaks on time related datatypes and minor editorial

>A proper use of a timeDuration would be that the movie runs "PT1H22M".
>I believe that your interpretations is that
>"2000-01-23T13:00:00-06:00/PT1H22M" would also be a valid timeDuration
>which I believe is a misinterpretation of the datatypes document.

If you see a duck you expect it to quack not bark.  Since the the WD authors
based the timeDuration format on ISO8601 and the WD wording that describes the
'pinning' of a duration is similar to ISO8601, I think it's reasonable to expect
they meant to use the pinning format from ISO8601.  Only they know for sure, of
course.

>I'm curious how you would propose doing bound checking on a timePeriod.
>If a minInclusive constraint is added to a timePeriod, is one time
>period less than another if its duration is smaller or if it started earlier.

If a new type 'timePeriod' were to be defined as "a time interval with specific
start and stop times", I'm not sure you could constrain it with currently
defined terms.   You'd probably need facets like 'minStart', 'maxStart',
'minEnd', 'maxEnd', 'minDuration', and 'maxDuration'.   The point I wanted to
make though was that defining a datatype that requires 2 or more attributes to
express would add another level of complexity in validation.

From your earlier example:
"<quietPeriod start="1999-11-05T12:00:00Z" end="1999-12-17T00:00:00Z"/>"
What schema grammar would you generate to describe the datatype expressed as the
'start' and 'end' attributes?  What's wrong with expressing it as one attribute
"1999-11-05T12:00:00Z/1999-12-17T00:00:00Z"?

>It is the "quite useful" phrase that bothers me in that it indicates that
>the time zone qualifier could be used to transmit an additional piece of
>information other than the instant in time something happened. For example,
>along the lines of the flight example:

Let me get this straight: "it's too useful and should be restricted?" (you
walked into that one<g>)  No one is going to be passing nuclear secrets via the
time zone offset and you can't always protect application developers from
themselves.  The processing cost to calculate and apply a time zone offset is
trivial compared to the rest of the Gregorian Calendar.  A standard that allows
you to specify years > 9999 but not a 1 hour offset from UTC would seem a little
inconsistent.

george


-----Original Message-----
From: Curt Arnold [mailto:carnold@houston.rr.com]
Sent: Sunday, January 23, 2000 3:20 PM
To: George T. Joseph
Cc: www-xml-schema-comments@w3.org; xerces-dev@xml.apache.org;
petsa@us.ibm.com
Subject: Re: More tweaks on time related datatypes and minor editorial


George Joseph wrote:

> 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.

The ISO8601 document seems to be sloppy in distinguishing time periods (the
interval between two specific time instants) and time durations (a specific
quantity of time without any connection to a particular time instant).  From
the lexical pattern and reference to a section 5.5.3.2 in the datatypes
document, I'm confident that the authors of datatypes meant the timeDuration
datatype to be exclusively the latter.  On this I don't think that I am
proposing or suggesting anything, I'm just trying to clarify the
interpretation of the document.  A proper use of a timeDuration would be
that the movie runs "PT1H22M".  I believe that your interpretations is that
"2000-01-23T13:00:00-06:00/PT1H22M" would also be a valid timeDuration which
I believe is a misinterpretation of the datatypes document.  I'm not sure
that Ashok picked up on that in his reply to your question when he said he
agreed with all your interpretations.

If datatypes wants to support time periods, then at least it needs to be a
different datatype than timeDuration.  However, I think that falls into the
definition of an aggregate datatype that are outside the stated scope.

You mention that representing a time period as separate attributes is
disadvantageous for constraint checking.  I'm curious how you would propose
doing bound checking on a timePeriod.  If a minInclusive constraint is added
to a timePeriod, is one time period less than another if its duration is
smaller or if it started earlier.

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

It is the "quite useful" phrase that bothers me in that it indicates that
the time zone qualifier could be used to transmit an additional piece of
information other than the instant in time something happened.  For example,
along the lines of the flight example:

<Flight arrival="2000-01-23T06:00:00-06:00"  arrivalAirport="IAH"/>
<Flight arrival="2000-01-23T13:00:00+01:00" arrivalAirport="CDG"/>

Both these planes arrive at the same time instant.  However, they are
expressed in the time zone of the arrival airport and an application could
try to use to time zone offset to imply the time zone of the airport.  If
the timeInstant datatype strictly conveys a time instant then
"2000-01-23T06:00:00-06:00", "2000-01-23T13:00:00+01:00", and
"2000-01-23T12:00:00Z" (and 21 other time zone offsets) should be
interchangable.  Then the question is what value is added by allowing the
expression of the offset and does it justify the extra processing cost on
comparisions and the potential for misuse.

Ashok had mentioned that the time related datatypes are currently being
rewritten,  I am also anxious to see what they come up with and hope that
they resolve these and other issues that I've previously commented on.

Received on Sunday, 23 January 2000 21:05:58 UTC