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

[Syd Bauman]

> Would it not be simpler to make the "complex" attribute sets
> optional? ...

Yes, it would, and the plan you outline is quite reasonable I think.
But it's basically the equivalent of C "class level".


> Agreed. So if a user wanted to mix a Gregorian with a non-Gregorian
> calendar in the same document (which seems to me quite reasonable),
> I can see how they could do that with A and D, but how to do that
> with B and C?

With B ("datatype level") the user would

1. create a datatype for the calendar of interest, 'data.myTemporal'
2. either
   a) add a new attribute to <date> (or better still, att.datePart)
      called myValue= which is declared as data.myTemporal, or
   b) add a new element, <myDate>, whose value= attribute is declared
      as data.myTemporal

With C ("class level") the user would

1. create a class for the calendar of interest, 'att.datePart.mine',
   which declares the myValue= attribute appropriately
2. either
   a) add <date> to att.datePart.mine, or
   b) create <myDate>, and make it a member of att.datePart.mine

In both cases step 1 involves messing with ODD, which some have
suggested we should try hard to avoid. It is more likely that
solution C step 2(a) could be done via check-box in a Roma tool than
any of the other step 2 possibilities.


> If B (datatype level), then the mixed-calendar encoder would have
> to select the "loose" data type for all dates (the "lowest common
> denominator" data type),

Right, unless they created another attribute as above. This is a bit
of a disadvantage of datatype level.


> If C (class level), then you suggested 2 options:
> C(1): classes use different attribute names, hence can be mixed (from
> the encoders' perspective this is the same as option A, just implemented
> using classes); or
> C(2): classes use the same attribute names, hence they can't be mixed
> (from the encoders' perspective this is like option B)

I think that is a reasonable summary. But keep in mind that
* "just implemented using classes" will be, for some users, a
  sizable advantage;
* no one has suggested a mechanism for actually implementing C(2).


> I just meant that it was an attractive idea to have date/@value
> rather than date/@iso-value and date/@w3-value (or whatever), since
> a date, no matter how you express it, is still just a date.

Understood.


> I think that's a strange implication to take. cf @xml:lang and
> @xml:id which are inarguably (I hope?!) part of the TEI markup
> language, despite belonging to a distinct namespace. Remember, too,
> that all the other "TEI" attributes are not in fact in any
> namespace. An XML markup language is quite a different beast from
> an XML namespace. But hey, I'm not fussed about the idea ... it was
> just a suggestion.

Good points, although I would argue that xml:lang= and xml:id= are
somehow different. But as long as foo:bar= is in the TEI Guidelines
and TEI schemas, it is in a very real way part, albeit a separated
part, of the TEI language.