[tei-council] two <date> proposals: 1 lumping, 1 splitting

[Syd Bauman]

lumping
-------
We currently have two attribute classes for attributes directly
related to dates & dating:

  att.datePart (should be 'att.dated') --
  provides value= and dur= to:
      <date>, <day>, <distance>, <hour>, <minute>, <month>,
      <occasion>, <second>, <time>, <week>, <year>

  att.datable --
  provides notBefore=, notAfter=, from=, and to= to:
      <acquisition>, <affiliation>, <binding>, <birth>, <custEvent>,
      <date>, <death>, <education>, <faith>, <floruit>,
      <langKnowledge>, <langKnown>, <nationality>, <origDate>,
      <origin>, <persEvent>, <persName>, <persState>, <persTrait>,
      <provenance>, <relation>, <residence>, <seal>, <sex>,
      <socecStatus>, and <time>

It has been suggested that these two classes be merged. While at
first look this seems to me like a very good idea. After all, any
element that is in att.datable is there so one can describe rough
dates about it. If one knew an exact date, one would be happy to use
it, and
    value="2006-09-10"
is a lot nicer than 
    notBefore="2006-09-10" notAfter="2006-09-10"

But on closer examination, it certainly makes no sense to have a
value= attribute on <persName> or <langKnown> that is a date! For
that matter, the idea of using notBefore= and notAfter= on a <minute>
element is a bit far-fetched.


splitting
---------
Currently we support only W3C recommended formats for normalization
of date & time format via data.temporal and data.duration, with one
exception that I insisted on: that times can be expressed with
reduced precision.

Emerging from a conversation with the author of a date-related
feature request is an idea to simultaneously support both W3C
recommended and ISO standard formats. We would have two different
formats, data.temporal.w3c and data.temporal.iso. The former would
just use the W3C recs w/o that horrific regexp to permit reduced
precision times. The latter would be full of horrific regexps[1] to
constrain it to the ISO 8601:2004 standard (which permits quite a few
things W3C does not, e.g. times w/ reduced precision, the year "0",
time spans indicated by duration & end-point, etc.).

Users could then choose, in their ODD, whether they wanted to go the
easy but limited W3C route that has guaranteed software support, or
the kitchen sink but no software ISO route. We would get to argue
over which is the default.


In anticipation of a point James would raise, yes, there is no point
in having from=, to=, or dur= in the data.temporal.iso case. On the
other hand, without making two separate, mutually exclusive modules,
I don't see how we could support that. (A Schematron check might
point out when one of these attributes and data.temporal.iso is
present, but that's not what users would want, which is not to have
those attrs in their document creation schema at all.)


Notes
-----
[1] At least until someone writes a nice datatype for ISO dates, then
    we just use it :-)