> > it ends uplike this:
> > <date>2011-02-28 15:34:08</date>
> > so there are no T present.
> How some programming language handles
> these details is irrelevant. We should
> stick to ISO 8601.
I also consider that it is good to try to stick to ISO 8601. If some 
specific non-standard-compliant software has a bug and forgets the T in 
its outputs, it should be quite easy to write an XSLT to fix that 
afterwards. Maybe someone on the list already has such an XSLT to be used 
in different contexts.

> * #206 Calendar week e.g. 1985W15 (week 15 of 1985)
I would suggest to add a little note about the circumstances when it would 
be encouraged to write 1985W15 and when it would be encouraged to write 
1985-04-08/P7D instead.

> so slap me upside the head
I have absolutely no reason to use any kind of violence! On the contrary, 
it seems that we could agree about the fact that there may be no reasons 
to have a feature whose usefulness is (as of today) not obvious and which 
definition is built on a coarse approximation.

My message was that I consider it is good practice to try to be aware of 
the limitations of our specs, even when those limitations may seem 
distant. Awareness helps to write a better documentation and good 
documentation today will help for a better future awareness of these 
limitations, which helps us to avoid inconsistencies in our (future) 

Different (small) shortcommings and inconsistencies which, one by one, may 
seem negligible can sometimes be far less negligible if they happen to 
occur together. Maybe you wonder whether I have an example for that in the 
context of this spec. But: If I had an example, it would be a use case.