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

[Sebastian Rahtz]

Syd Bauman wrote:
> CW> we should not carry the class economy to far, I think. Having
> CW> attributes that do not make sense for a certain element should
> CW> automatically recommend it for a separate class.
>
> SR> no worries. I am sure someone will find an amusing use for @dur
>
> I'm with Christian on this one. (In part because I think Sebastian is
> right, and the amusing use of dur= worries me.) 
>   
I'll concede that one, not a strong feeling on my part
>   
> CW> att.datePart.date?
>
> SR> att.dateValue
>
> Hmmm... how about att.normalizedDate?
>   
sure
>
> SR> If you switch to an ISO or USER model, would you do it piecemeal?
> SR> wouldn't it always be a global decision?
>
> Not at all! Most obviously, I probably want the date= of <change> to
> be a simple format date (W3C) even if I need to use the complex date
> format for the value= of <date> that is inside my transcription of a
> 17th century diary.
>   
OK, I see the example, but that makes it even more important
not to use the same attribute.
> are.) To ascertain what kind of date it is processing, software need
> only 
> * follow the link in the yet-to-be-agreed-upon-let-alone-specified
>   mechanism in the instance that points to the schema;
> * find the declaration for the attribute in question;
> * see what kind of datatype it is declared as.
>   
IF (a big "if") we mandated the "yet-to-be-agreed-upon-let-alone-specified
 mechanism in the instance that points to the schema", I could
sort of go along. But for TEI P5 1.0, I just don't see this
work being completed and implemented by anyone.
> One attribute, syntax of value determines what kind of date format: 
>
>   no prefix   = entire value is a simple format (i.e. W3C) date
>   prefix 'i-' = remainder of value is an ISO 8601 date
>   prefix 'x-' = remainder of value is a user-defined format date
>
> Thus:
>
>   <date value="2007-02-14"/>
>   <date value="i-2007-W07-3"/>
>   <date value="x-1385-11-25"/>   <!-- Persian calendar -->
>   <date value="x-hebrew-5767-11-27"/>
>   <date value="x-islamic-1428-01-27"/> 
>   
I would not actually blow up Parliament in protest
if we adopted that, but I still don't like the idea
of @value sometimes being valid with standard
datatypes and sometimes not.
> None of the user-created formats are ever going to have standard
> software suite support, so I don't think we should fret much over
> that.
agreed. but at least lets isolate them in their own names.
>
> So, IMHO, we are down to either class-level or all-in-one. 
>   
thats progress.

....
> By default, the various elements are members of the superclass. I.e.,
> <date> and <time> are members of att.dateTime and att.duration. If a
> user really does not want the plain W3C flavor attributes, she can
> delete att.dateTime.w3c and att.duration.w3c.
>
> On thought on this last bit: why doesn't she just make <time> and
> <date> direct members of att.dateTime.iso and att.duration.iso? My gut
> instinct is that this provides more flexibility: I can have <date> be
> a member of att.dateTime.w3c, <time> be a member of att.dateTime.iso,
> and my new <period> a member of att.dateTime, thus getting both
> attributes.
>   
Sure. Thats just a design pattern, though. The underlying
system remains the same. The default is to be a member
of the superclass, right?
>
> SR>  * people who want to define att.datable.Etruscan as a new class simply
> SR>    do so, and change att.datable to be member of that new class
> SR>  * if desired, individual elements can be made members of 
> SR>    att.datable.Etruscan
>
> Right, which is why the "UserDate" module and various .usr classes may
> not be needed.
>   
Yes. It does seem slightly simpler to define each new scheme
as a new class, rather than overload one "usr" class.
> SR> I believe that the complexity of adding an extra set of attributes
> SR> is worth it for the simplicity and extensibility.
>
> Can you elaborate on how this is more simple or more extensible than
> the "all-in-one" solution? I think "all-in-one" is simpler for the end
> user, and not particularly more complicated for the programmer. 
out of the box, what would the the datatype of @value be?
how do I indicate that I am happy in a Barbie^H^H^H^H^H^HW3C
world, and I want all the datatype checking my standard
software can provide me? or how do I switch to alternate mode?

my aim would be for the simplest situation to require no
work for the user, and maximum support.

....
> Indeed. Although personally, I'd be inclined to add the .iso class at
> 1.0, and then work on a datatype to actually constrain it well for
> 1.1. 
>   
sure, no problem

as I read your message, you've more or less
persuaded yourself to agree with my class
proposal a la att.global?

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