[tei-council] date attributes: summary, problems, and some suggestions

[Sebastian Rahtz]

Thoughts on dates
> Problems
> --------
> * Some are distressed by the fact that attributes that are of the
>   same datatype (data.temporal) and serve similar functions have
>   different names, in particular:
>       value=  of  <date>, <time>, <distance>, and <docDate>
>       date=   of  <birth>, <change>, and <death>
>   I am not bothered by this in the least, because I think the
>   semantics are clearer with these names, and the combined
>   alternative (dateValue=) is at least cumbersome if not misleading
>   (i.e., on <time>).
>   Suggestion: leave names as they are. 
>   

OK. its a minor annoyance/distress, but not worth arguing about
> * We haven't implemented classes as well as we could.
>   Suggestions: 
>
>   - Put <docDate> into att.datePart. This has the disadvantage of
>     giving <docDate> a dur= attribute, but I'm not sure it is worth
>     making another class just for this one case. Thoughts?
>   
no worries. I am sure someone will find an amusing use for @dur
>   - Create a new attribute class for the date= of <birth>, <death>,
>     and <change>. (Any suggestions for the name?) 
>   
att.dateValue
>   - If we keep <distance>[1] we may wish to reconsider its class
>     membership, as value= is a bit silly on <distance>. It needs only
>     dur= from att.datePart, making two cases that benefit from
>     splitting att.datePart. (See <docDate>, above.)
>   
kill distance
> * The precision= attribute is superfluous, as the precision is
>   ...
>   Suggestion: delete it.
>   
OK
> * Users want a method of expressing things like "Oct 27 of 1909, 1910,
>   or 1911" or "an Oct 27, but I don't know which one". The W3C format
>   that express only a month and day explicitly (xsd:gMonthDay) means
>   "a set of one-day long, annually periodic instances". These users
>   don't want the entire set, they want only one. ISO 8601:2004 does
>   not seem to have even a method to represent the set, let alone a
>   singleton. (James, can you verify that? How would one represent
>   month & day, no year, in 8601?)
>   Suggestion: I haven't got one, thus defer to P5 1.1.
>   
I agree.
> The basic idea is to provide two capabilities: 
> * simple date format: conform to W3C spec, easily validatable, software
>   support in the world-at-large
> * complex date format: should conform to ISO 8601 if possible
>   
The principle is fine, yes.

I would rule out the attribute level solution, just too confusing
for day to day use.

The class solution is sort of elegant, but falls down
somewhat in implementation problems.

The all-in-one solution is cute, but presumably not
supported by validating software or other standards?

The multiple datatypes are interesting, but "the users chooses which 
datatype
to use for any given attribute" is a bit clumsy. If you switch to an ISO
or USER model, would you do it piecemeal? wouldn't it always be a
global decision? 

More importantly, this means that when I see <date value="foo bar"> coming
at me, I cannot easily deal with it without parsing the ODD in relatively
complex ways. I really don't like the idea of @from and @to changing
their meaning under my feet constantly, or having to refer back to
ad hoc notations in the header.

What to do? I think we should basically go with the class
solution, and accept that elements will gain extra
attributes of the form value.XXX etc.

We implement it as follows:

 * make  all the relevant elements members of att.datable
 * make att.datable a member of att.datable.w3c and att.datable.iso
    (att.datable.iso is empty initially)
 * att.datable.w3c defines short forms attributes like "value" and "from"
 * in a new module (namesdates_complex) define a att.datable.iso
    which defines value.iso and from.iso
 * if the new module is loaded, all the relevant elements now get extra
    attributes
 * people who don't want the standard attribute kill the att.datable.w3c 
class
 * people who want to define att.datable.Etruscan as a new class simply
   do so, and change att.datable to be member of that new class
 * if desired, individual elements can be made members of 
att.datable.Etruscan
 * people can redefine att.datable.w3c to use ISO if they want
   to freeze in hell forever and ever

We have to set up a new module, of course, for the quick switch.

I believe that the complexity of adding an extra set of attributes
is worth it for the simplicity and extensibility.

The model I am following here is that of att.global, which picks up
extra meaning if you load new modules

If you buy the "module" route, it means that we could add
att.datable.iso at 1.1 if we wanted.

Note: having discussed this with Lou, he says he agrees,
and so won't reply to this thread on his own.


-- 
Sebastian Rahtz      

Information Manager, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

OSS Watch: JISC Open Source Advisory Service
http://www.oss-watch.ac.uk