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

[Syd Bauman]

OK. I realize dating attributes can make your head spin -- heck, I
got so dizzy I had to take breaks while writing that last posting.
But given that we are in pedal-to-the-metal mode to get moving on P5,
I would like to avoid waiting for 2 weeks to see if anyone has
comments on it, only to find they don't.

Christian, Daniel, and Sebastian are working on getting a working
project management system up for P5, which will hopefully include
(among other things) a voting system for Council to use to express
its wishes. But that's at least days away, so in the meantime
Christian has authorized me to use the following far cruder system.

I really want each and every one of us to reply to this posting
within 72 hours having checked off one box for each of the following.


Issue: name of main dating attr (date= vs value=)
Solution: leave 'em as is
Vote:

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

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

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

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

     ___ 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:
     ___ A
     ___ B
     ___ C
     ___ D

         I have considered issue, and disagree with proposed solution:
     ___ A
     ___ B
     ___ C
     ___ D

     ___ It does not matter to me which solution is chosen, so go
         ahead with whatever

     ___ I have not yet had time to consider the issue sufficiently,
         but expect to contribute soon