[tei-council] datatype issues (part 1)

[Syd Bauman]

Lou Burnard writes:
> Thanks for the clarification, and apologies for my careless usage. Let's 
> see if I;ve understood the position correctly.
> (1) ISO 8601 defines a large  number of different formats for 
> representing temporal expressions
> (2) W3C has defined a subset of these for which named w3c datatypes exist
> (3) the edw90 proposal for tei.data.temporal is to allow a combination 
> of (some of or all?) the w3c datatypes plus a couple of others which Syd 
> proposes we should allow for as well by means of a pattern

Yes! That's it in a nutshell. (EDW90 does propose all the W3C
temporal types save duration be included; it only proposes the
addition of "time precise to the minute", but we may wish to add
"time precise to the hour" as well; I have not (yet) thought about
adding dateTime values (as opposed to time values) that are precise
to the hour or minute.)

One clarification, one caveat:

* Reminder to others that Lou's use of "pattern" in (3) is that of
  'W3C pattern facet', not a RelaxNG pattern. (The whole thing is a
  RelaxNG pattern.)

* In truth, there are quite a few other differences between W3C dates
  & times and ISO 8601 representations, which I didn't think we
  should concern ourselves with. Others may disagree, though. The
  list is at http://www.w3.org/TR/xmlschema-2/#deviantformats.


> If that's correct, the only issue we have to argue about is whether
> or not the 'extras' are desirable enough to outweigh the possible
> inconvenience of supporting formats which off-the-shelf
> w3c-focussed implementations may not recognise.

Since

a) I've yet to see any example of software that does something
   useful with "13:14:54" but barfs on "13:15", and
b) users aren't *required* to be imprecise

I think the extras are well worth it.


> I don't have a strong view on this: we could maybe distinguish
> tei.data.temporal and tei.data.temporal.extended if others do --
> the distinction being that the former keeps to our original goal of
> mapping cleanly to w3c datatypes.

A bit of a side-note: to me the proposed
   xsd:date | xsd:time | ... | xsd:token { pattern = "[whatever]" }
*is* mapping directly to W3C datatypes. (I had not contemplated this
"cleanly" business before :-) That is, nothing more than an average
RelaxNG validator that knows the W3C datatype library (e.g., jing,
xmllint) is needed to validate it.