[tei-council] dating attributes
Syd_Bauman at Brown.edu
Sun Oct 8 20:26:54 EDT 2006
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.
> - 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
> 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
> 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.
More information about the tei-council