[tei-council] what to do with dating attributes -- VOTE!

Conal Tuohy Conal.Tuohy at vuw.ac.nz
Thu Feb 15 20:49:18 EST 2007


Here's my 2c

> Issue: name of main dating attr (date= vs value=)
> Solution: leave 'em as is
> Vote:
> 
>      _X_ I have considered issue, and agree with proposed solution
> 
>      ___ I have considered issue, and disagree with proposed solution
> 
>      ___ It does not matter to me which solution is chosen, so go
>          ahead
> 
>      ___ I have not yet had time to consider the issue sufficiently,
>          but expect to contribute soon
> 
> 
> Issue: classes -- @dur and @value in same or different attr classes?
> Solution: split 'em into separate classes
> Vote:
> 
>      _X_ I have considered issue, and agree with proposed solution
> 
>      ___ I have considered issue, and disagree with proposed solution
> 
>      ___ It does not matter to me which solution is chosen, so go
>          ahead
> 
>      ___ I have not yet had time to consider the issue sufficiently,
>          but expect to contribute soon
> 
> 
> Issue: keep <distance>?
> Solution: nuke it
> Vote:
> 
>      _X_ I have considered issue, and agree with proposed solution
> 
>      ___ I have considered issue, and disagree with proposed solution
> 
>      ___ It does not matter to me which solution is chosen, so go
>          ahead
> 
>      ___ I have not yet had time to consider the issue sufficiently,
>          but expect to contribute soon
> 
> 
> Issue: keep precision= of <date>
> Solution: nuke it
> Vote:
> 
>      _X_ I have considered issue, and agree with proposed solution
> 
>      ___ I have considered issue, and disagree with proposed solution
> 
>      ___ It does not matter to me which solution is chosen, so go
>          ahead
> 
>      ___ I have not yet had time to consider the issue sufficiently,
>          but expect to contribute soon
> 
> 
> Issue: method of expressing known day & month, unknown year, or
>        specific possible dates within a range
> Suggestion: defer to P5 1.x.
> Vote:
> 
>      _X_ I have considered issue, and agree with proposed solution
> 
>      ___ I have considered issue, and disagree with proposed solution
> 
>      ___ It does not matter to me which solution is chosen, so go
>          ahead
> 
>      ___ I have not yet had time to consider the issue sufficiently,
>          but expect to contribute soon
> 
> 
> Issue: constraint of date-regularization attributes: W3C, ISO, other
> Suggestions:
> A ("attribute level"): duplicate current attrs for each 
> different system
> B ("datatype level"): create duplicate datatype for each different
>                       system
> C ("class level"): create classes for each set of attrs from
>                    different systems; possibly implement with a new
>                    module so attrs are added when that module is
>                    loaded (like att.metrical gets added to
>                    att.divLike when verse is loaded)
> D ("all-in-one"): differentiate system by value's syntax
> 
> Vote:
> 
>          I have considered issue, and agree with proposed solution:
>      _X_ A
>      ___ B
>      ___ C
>      _X_ D
> 
>          I have considered issue, and disagree with proposed solution:
>      ___ A
>      _X_ B
>      _X_ C
>      ___ D
> 
>      ___ It does not matter to me which solution is chosen, so go
>          ahead with whatever
> 
>      _X_ I have not yet had time to consider the issue sufficiently,
>          but expect to contribute soon

That last one is tricky. 

I'm not sure, Syd and Sebastian, why you have characterised the
"attribute-level" solution (A) as NOT making the easy things easy, and
"just too confusing for day to day use". Could you clarify where the
confusion might lie please? It seems to me that we could have <date
value="2007">this year</date> and that this is easy. So I must be
missing something.

I think B and C are weaker (if I understand them correctly) in that they
would prohibit mixing calendars in a document (at least, with the same
element, so that date/@value would have to have a consistent type
throughout a document). Is that a correct understanding? Would that be a
problem for historical markup? Maybe not, in which case the objection is
probably moot. However, options A and D would allow mixing calendars. In
some ways I prefer D because it implies that the attributes have
particular semantics which are in a sense independent of the particular
calendrical "syntax" used. But on the other hand I'm not sure that it's
possible to make a hard-and-fast distinction between syntax and
semantics anyway (not in every case at least, since days and years are
pretty standard features of calendars; weeks, months, katuns, etc are
less so). The advantage of A of D would be that the attribute VALUES are
kept "clean" without TEI-imposed prefixes.

All in all, I feel quite ambivalent (multivalent actually!) about these
options.

Incidentally, if option A were favoured (whether as part of option D or
otherwise), one way to implement it might be to use distinct XML
namespaces for the different data types. We could have the default,
W3C-typed, attributes in no namespace (as they are now), and allow
customisations to add date-type attributes in other namespaces. Encoders
could then use whatever namespace prefixes they wanted to e.g. either at
one extreme <date iso-8601:value="--0301">St David's day</date> or at
the other <date i:value="--0301">St David's day</date> depending on
their preference.

Cheers

Con



More information about the tei-council mailing list