[tei-council] two <date> proposals: 1 lumping, 1 splitting
James.Cummings at computing-services.oxford.ac.uk
Mon Sep 11 06:33:16 EDT 2006
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?)
More information about the tei-council