I think this is a good and interesting test case for all the implications of deprecation and Birnbaum. As many people frequently remind me, Birnbaum does _not_ mean that you can't break backwards compatibility; it means that when you do, you must have sound reasons for it. In this case, Council deliberated for a long time, concluded there were sound reasons, and then implemented a two-year deprecation period. That's a perfectly reasonable and intelligent way to proceed, and it worked as planned. The issue of whether ENRICH should change to stay in line with the TEI has nothing to do with the Birnbaum doctrine; it's an issue for ENRICH. If the purpose of ENRICH was to create an unchanging schema for the ages, then the solution is simple: customize the ODD to replace the attribute. If ENRICH is a going concern that will want to stay current with a changing TEI, then it needs its own mechanisms for deprecation, perhaps, or its own Birnbaum doctrine, or both. It's not really something for the TEI Council to worry about, unless ENRICH is an official product of the TEI, which I don't think it is; if I'm wrong about that, then we should raise a ticket and discuss what should be done with ENRICH in the normal way. If that's going to take substantial time, we could temporarily remove it from the regular build process. Cheers, Martin On 14-12-20 01:00 PM, Lou Burnard wrote:
On 20/12/14 20:56, Sebastian Rahtz wrote:
On 20 Dec 2014, at 20:42, Lou Burnard
wrote: Deprecation is all very well, but it's no reason to break Birnbaum! hmm. thats surely exactly what we are doing when we deprecate, and then remove something?
Well my opinion is that in this particular case, for reasons already stated, zeal to remove things we now think we would prefer to do otherwise is not a sensible idea. t will simply annoy and confuse people.
you can’t have your cake and eat it.
Too right. I have toothache.