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

[James Cummings]

Syd Bauman wrote:
> 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.

While far-fetched on minute, I could see it maybe on year/month/week/day/hour I
suppose.  (Though I don't think I'd use those that way, who knows.)
> 
> 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.

This seems an apt solution (data.temporal.w3c and data.temporal.iso), and I
would assume that the more straightforward option w3c would be the default even
if I might prefer to use the iso version.

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

I guess I am predictable in my devil's advocate advice. *sigh*  But yes, that is
exactly what I was going to say. :-(  But at least I express an opinion!

That said, I say leave them in both cases.  It gives users choice.  They can
then use from and to to indicate specific dates in ISO format without using the
ISO Period/Duration notation.  Maybe there is some reason that they might feel
this is more appropriate to their use? (Ease of processing, data entry. legacy
conversion, or something?)


-James