> > 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
> 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.