On 15-06-09 08:12 AM, Lou Burnard wrote:
On 09/06/15 16:06, Syd Bauman wrote:
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.
Um, I think we have done that precisely once, so far. Is that really very hostile ?
We've made changes to classes a few times -- creating att.source and att.global.rendition are recent examples. The latter proved slightly inconvenient for customizers, but to be fair it was flagged well in advance, having arisen out of a lengthy discussion on TEI-L, and when I made the change initially (months before the actual release containing it) I announced it on TEI-L and suggested that customizers could get a preview of it from the Jenkins build. But it does sound like we need an explicit policy here. We have the policy that anything affecting validation undergo two years of deprecation before implementation; but we don't have any clear rules for changes affecting existing customizations.
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?)
I think you may be.
Changing what we do in the Guidelines is obviously step 1 (eating our own dog food). But I think we should probably be thinking along the lines of creating a page on the wiki which introduces and explains Pure ODD in detail, so that customizers can get a good early look at it before it's integrated into the Guidelines prose. Cheers, Martin
BTW, is there a reason <datatype minOccurs="1" maxOccurs="3"> <rng:ref name="data.count"/> </datatype> should stop working when 'data.count' is defined by a <dataSpec> rather than a <macroSpec>? I had thought it would continue to work.
"data.count" is never going to be defined by a <dataSpec>. The proposal is to use a different name e.g. "teidata.count".