- From: Arnold, Curt <Curt.Arnold@hyprotech.com>
- Date: Mon, 8 Nov 1999 15:08:15 -0700
- To: "'www-xml-schema-comments@w3.org'" <www-xml-schema-comments@w3.org>
3.2.4.1 time zone offset In the second paragraph, you say time zone offset is + or - followed by hhmm. The example uses hh:mm. Either would be acceptible ISO usage, however for consistency with using the extended form else where I would recommend hh:mm. 3.2.5.1 timeDuration lexical representation b) The current ISO 8601 section 5.5.3.2.1 is ambiguous whether a P is required before a time period. It could be implied from section 5.5.2 which says that a P should preceed a duration. Section 5.5.4.2.2 in the draft revision is explicit that a P is to preceed that alternative format. The example would then be P0001-02-03T10:30:00 D.3.2 What would be the interpretation of a negative timeInstant (years BC?). What is the interpretation of a recurringInterval with a negative duration? I think you must constrain the period of recurringInterval to non-negative durations or explicitly state that a negative sign is ignored (or switch to the primary ISO representation of durations). Applications that want to adhere to ISO8601 can create derived datatype's with minInclusive of 0 to prevent the occurrence of negative dates. D.3.3 Lexical Representation for Time Period Time Period was introduced as a concept in 3.2.5.1 but was not implemented as a type. I think you meant this section to be titled "Lexical Representation for timeDuration". If you prepend the P, then the timeDuration format proposed would be the alternative form for timeDurations in section 5.5.3.2.1 of the current ISO draft. Why was month == 30 days concept added. If you do this, then there is not a way to create a data type that represents a specific day in each month (since <period>0000-0100</period> would be interpreted as <period>0000-0030</period>. If you do this, why not year==365 days, century == 36500 days. The alternative form in IS0 8601 does have problems if you wanted to say a duration of 300 days. Though it seems to save a little parsing problems, I think that we would save a lot of long term problems by sticking with the primary ISO representation of time periods. How much more complex could validating periods against PnYnMnDTnHnMnS be? p.s. There is a misspelling of digit as dgit in the description of C in section D.1.
Received on Monday, 8 November 1999 17:11:11 UTC