I'm confused, probably because I missed some part of important
discussion. So apologies in advance, but it sounds like you're
talking about having datatypes in the TEI Guidelines defined by both
<datatype> and <dataSpec> simultaneously. This seems like overkill to
me. While we are careful not to break backwards compatibility for TEI
*users* w/o good reason and deprecation, we are all but outright
hostile to TEI *customizers*, frequently changing classes out from
under them w/o warning.
Personally, my first reaction is that a (6-month) warning is a good
idea, but otherwise we should go ahead and change our <datatype>s to
<dataSpec>s. (Unless I'm missing something, here?) The TEI Guidelines
and associated stylesheets need to support both during the
deprecation period, of course, before <datatype> can be dropped from
the Guidelines -- i.e., before the definition of <datatype> can be
dropped from the Guidelines, as opposed to its internal use.
BTW, is there a reason
<datatype minOccurs="1" maxOccurs="3">
If we are to abide by Martin's eminently suggestion
You cunningly left the adjective for the reader to supply there, but I don't think we have any option here, do we?
the word i failed to type was, of course, "sensible"
We have to deprecate anything we're going to remove for a period of two years, as Syd reminded me recently wrt the defaultVals.
of permitting the new pure odd dataRef to coexist with the current <dataype> mechanism, I can't see any way out of doing the following
I don't think I was suggesting that <datatype> and <dataRef> both be available in a Pure ODD structure, was I? I think I would have meant that the old mechanisms will have to continue to be supported almost indefinitely, but within Pure ODD structures it would be better to use only Pure ODD elements
Not entirely sure what a "pure ODD structure" is, tbh, but clearly there's no reason for "pure odd" to continue to support legacy ways of doing things. Or we will never make any progress. And note that going over to using pure odd isn't going to affect the 95% of the TEI community which does not write its own ODDs.
. [...]
c) the current section 1.4.2 on datatype macros (#DTYPES, in #ST) will also need to be cloned, or substantially revised, since this is where the pesky things are actually defined
The chapter prose would have to be expanded anyway, wouldn't it? it
Or contracted. Don't forget there are two sections concerned: one where we talk about the ODD elements (#TD) and one where we actually say what datatypes the TEI provides (#DTYPES). I'm trying (but failing) to avoid having to double the size of the latter. For a moment I even toyed with the idea of abandoning those TEI dataypes which map directly onto an existing W3C schema datatype, since we can use dataRef to point specifically to the latter. But my better self wouldn't let me.