From: C. M. Sperberg-McQueen
Sent: Tuesday, January 11, 2011 1:14 PM
Addressing remaining issues (not covered in other threads)
> 3 What problem is being solved here? What are the requirements?
> The goals and requirements of the work are not clear (to this reader,
> at least) from the document. The section 'Background' begins with the
> promising statement
> No standard date/time format meets the needs of XML metadata
> But the document does not seem to provide any list of what its authors
> believe the needs of XML metadata schemas are, or why no existing
> standard date/time format meets them.
While I have for the past couple months worked to maintain the spec page,
the other pages, background, requirements, etc., have suffered from lack of
attention. My fault, and I will turn my back attention to them soon.
My colleague Rebecca Guenther has been working closely (though relatively
silently) with me on this and I have asked her to address issues of use
cases, requirements, etc, so look for a message from her in a day or so.
> 4 Why a single datatype?
> Is it a requirement that all of these formats be defined as lexical
> forms for a single datatype?
No, it is not a requirement, it is a design strategy. It is open for
> Is an interval really the same as a duration the same as a date the
> same as a time the same as a date-time pair?
No. The spec defines a syntax for an interval, and a different syntax for
duration, and syntaxes for time and date-time pairs. I'm sure I'm
misunderstanding your question so please elaborate.
> 6 What operations are expected?
> When sorting by values of this type, how should questionable,
> approximate, and uncertain dates be handled? How does a time like
> 22:00:22 compare to a date like 2011W02?
I would think it reasonable to declare these out-of-scope for the spec and
the responsibility of the application that defines or uses the data.
> 7 The year zero
> Entry 110 reads in part
> BC has no year zero, In the BC system the year before year 1 is 1
> BC. Thus '-0999' means "1000 BC".
No longer. BC and AD are no longer discussed in the spec so this is no
longer an issue.
> And ISO 8601 sets a heroic example of allowing a multiplicity of forms
> while ensuring that any form conforming to the spec is unambiguous. It
> looks at first glance as if allowing hyphen to separate the start and
> end points of a range or interval (as shown in 317 and 319) is safe,
> because the hyphen (or double hyphen, in 319) is followed by four
> digits, not two or three. If you have done the work necessary to
> guarantee that you are preserving 8601's lack of ambiguity, it might
> be worth saying so in the prose; if you haven't done the work, it
> would be useful to do it.
We're currrently re-examining whether we need to keep the compact form in
the spec, so I will defer this exercise until we resolve this.