[tei-council] dating attributes

[Syd Bauman]

First, a nit-pick that does not affect the proposal or my thoughts
about it, but should be corrected just in case this proclamation ever
gets read in the public square.

> INASMUCHAS
> - these attributes all have a datatype of data.temporal which being
>   expanded turns out to match simple w3c-conformant dates, or various
>   ISO formats, or one we dreamed up all on our own, and thus provide
>   headaches for simple minded validation software

There are no formats in data.temporal that we dreamed up on our own;
there are the various W3C conformant dates/times and one ISO
conformant date/time that is not W3C conformant. That is all.


Now back to our regularly scheduled response ...


> 1. all elements the content of which describes either a point or a
>    span in time should carry the same set of attributes, and
>    constitute members of the att.datable class

I note that this does not include, e.g., <persName>, the content of
which describes neither a point nor a span in time. Is this an
oversight, or are such things deliberately not part of this proposal?


> 3. @notBefore and @notAfter have the same significance as at present. 
>    Their datatype is data.temporal.user (see below)

I kinda like the data.temporal.user idea. But how do we get this to
be user-definable? I.e., what happens if the user *doesn't* define
it? "notAllowed" perhaps?

> 4. @normw3c contains a normalized representation of a nodern calendar 
>    date in W3C format, like the current @value. Its datatype is 
>    data.temporal.w3c

Sounds good.


> 5. @norm contains a normalized representation of a date in any 
>    user-chosen calendar according to a defined format. Its datatype is 
>    data.temporal.user, and the calendar is specified somewhere (not sure 
>    where) in the header.

Sounds reasonable. But is there a lot of demand to normalize against
a calendar other than either (proleptic-)Gregorian or whatever
calendar the content of the element (and thus its calender=
attribute) uses? My initial thought was that there is little or no
such demand, in which case we could think of this as a regularization
rather than a normalization, and use reg= for this, and norm= for #4
above. 


> 6. @exact indicates which ends of the date range indicate by
>    @notBefore and @notAfter can be considered exact: it has three
>    possible values "from" "to" "both". So for example
>    'notbefore="x" exact="from"' is equivalent to "from='x'"

I'm less keen on this idea. I'd much prefer to have all 4 attrs
(notBefore=, notAfter=, from=, and to=). 


> My first thought was that actually I'd rather have ISOnorm than
> normw3c but that may not be an option.

I would, too, and I bet James would, too. The problem is that there's
no off-the-shelf datatype to use. W3C provides a datatype library
that RelaxNG uses to validate the W3C date/time formats. If we wanted
to use the ISO formats we'd have to make our own datatypes. Shouldn't
be impossible, but would be a chunk of work.

And besides, as Sebastian is likely to point out, the software out
there in the wild primarily either doesn't know about dates at all,
knows only 1 particular probably proprietary format, or (like Saxon)
knows about W3C formats. I'm not aware of anything that knows how to
properly process ISO formats.