Saašha, thanks much for the comments.

> From: Saašha Metsärantala
> Sent: Monday, February 07, 2011 3:18 PM

> > the W3C built-in schema types
> I may be useful to specify which schema version is meant.

What do you recommend?  As I understand there is only one official version at present, 1.0.  Version 1.1 hasn't been approved as far as I can tell.  Does it matter though? Are any of the built-in types affected by the new version?

> > 109 Date and time (with colon)
> 109 Date (with hyphen) and time (with colon)


> > 203 need use case
> When the source reads 19th century (without specification of how the
> century is defined in this case)
> > 203 • 19 20th century • 00 first century
> We could reserve the term “century” to apply ONLY when the source uses
> the term “century” (or its equivalent in another language) without
> defining it. Thus, we would avoid any “wrong” definition of the the
> term “century“.
> When all the hundred years from 1901 (inclusive) to 2000 (inclusive)
> are meant, we could use 1900-01-01/P100Y. When all the hundred years
> from 1900
> (inclusive) to 1999 (inclusive) are meant, we could use either 1901-01-
> 01/P100Y

Ok, I've changed the status of "century" and added a note.

I also changed "Interval: start and duration", 211, status to "confirmed requirement".

(Note: 212, "Interval: duration and end" not affected, still need use case.)

> > 205
> When the capacity of computer memory was very limited, the month was
> sometimes (albeit seldom) written in hexadecimal. 85c18 was then
> december, 18th 1985. There is a risk for 1995109 to be missinterpreted
> as the ninth january 1995

I don't see the risk. It is unabiguously clear in ISO 8601 that a 7-digit value is a year and julian day. But it's not worth bothering with at this point until a use case is supplied. 

> > 210 20040101/20040102
> It could be good to specify why not use hyphens such as:
> 2004-01-01/2004-01-02

I added hyphens in 210, 211, and 212.

> > 213 the last of which occurs at
> It could be good to specify whether it begins or ends then

Changed "occurs" to "end", as I think that is the intent of ISO 8601. But this again is one that needs a use case (and I'm hoping we can remove it).

> > 215 T01:59:60
> There is an obvious risk to misinterpret that as a leap second

Another one currently without a use case, so no use trying to fix it until there is one. 

> > 301 to 311
> In the rightmost column, there is a typo: “co'on”


> > 316
> Square braces are quite error-prone as they make regexes more
> complicated for example. I would prefer c1667,1668,1670..1672 (with “c”
> for “choice”) instead of [1667,1668,1670..1672]

We'll have to make this a separate thread. 

> > 317 and 317 1
> Nothing on these rows indicates that it would be about approximations.
> If it is not an approximation, these rows should be move to a place not
> under this table header. 

Created a separate section, "Multiple Dates", for these two. 

> would prefer a1667,1668,1670..1672 (with “a” for all) instead of
> {1667,1668,1670..1672} because curly braces are error-prone both when
> it comes to regexes and XSLT where curly braces are used for attribute
> value templates. I consider that 2002-10-{03,05,09-12} could be
> rewritten
> 2002-10-a03,05,09..12 (with doubble dots as of 316, cf 323)

Separate thread. 

> > 319 to 322
> I suggest to use double dots instead of double dashes (cf 317, 323)

We already use double dots, see 317 ”double-dot indicates all the values between the two values it separates, inclusive." 

> > 325
> We could explore the possibilities to use QName as defined at

Separate thread.

> > 329
> It seems that “caret” is misspelled “carat”. 


> > 330 Should both syntaxes be supported or only one?
> The dotless version makes it easier to avoid non-integer values

Yes, we need further discussion on this.

> > 331
> Each winter in the northern hemisphere and summer in the south
> hemisphere covers two years. Maybe we should also introduce 25, 26, 27,
> 28. If 22 is the summer in the northern hemispere, 25 could be the part
> of the summer at the beginning of the year in the southern hemisphere
> and 26 could be the part of the summer at the end of the year in the
> southern hemisphere.
> Likewise, 27 and 28 could be used for the winter in the northern
> hemispere

It is my understanding that the proposed solution satisfies the requirement that has been presented.  I would prefer that someone indicate that they want southern hemisphere seasons represented separately before we try to represent them.

Thanks again!