- From: George T. Joseph <gtj@peakin.com>
- Date: Sun, 23 Jan 2000 21:03:54 -0500
- To: "Curt Arnold" <carnold@houston.rr.com>
- Cc: <www-xml-schema-comments@w3.org>, <xerces-dev@xml.apache.org>, <petsa@us.ibm.com>
>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