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 15:26:09 UTC