[tei-council] what to do with dating attributes -- VOTE!
Syd Bauman
Syd_Bauman at Brown.edu
Sat Feb 17 19:15:36 EST 2007
24 hours left, and we have votes from
- Sebastian
- Conal
- Lou (sent directly to me)
- Syd (below)
> Issue: name of main dating attr (date= vs value=)
> Solution: leave 'em as is
> Vote:
> ___ I have considered issue, and agree with proposed solution
> Issue: classes -- @dur and @value in same or different attr classes?
> Solution: split 'em into separate classes
> Vote:
> ___ I have considered issue, and agree with proposed solution
> Issue: keep <distance>?
> Solution: nuke it
> Vote:
> ___ I have considered issue, and agree with proposed solution
> Issue: keep precision= of <date>
> Solution: nuke it
> Vote:
> ___ I have considered issue, and agree with proposed solution
But I'm happy to be swayed by use-cases that require it.
> Issue: method of expressing known day & month, unknown year, or
> specific possible dates within a range
> Suggestion: defer to P5 1.x.
> Vote:
> ___ I have considered issue, and agree with proposed solution
I really don't like this, but see no other choice.
> 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:
> ___ A
> ___ B
> _X_ C
> _X_ D
>
> I have considered issue, and disagree with proposed solution:
> _X_ A
> ___ B
> ___ C
> ___ D
Currently I rank solutions as C = best, D = pretty good, B =
accceptle, A = a bit nuts.
More information about the tei-council
mailing list