Thanks for the lengthy explanation of your position, which is probably based on better information than I have to hand. You're right to point out that this won't affect people who are still relying on older versions of TEI, or compiled Enrich schemas, and also that those are probably the most numerous. A bit like P4 users, in fact! It will however cause confusion to anyone who has bought into the notion that because Enrich is a TEI application therefore data conforming to the Enrich schema will also be compatible with other TEI-derived systems. But maybe there are no such people. Will you continue to call your "new Bodley/CUL project" an "Enrich application"? That would suggest to me that files conforming to it would also load happily into Manuscriptorium. Which I don't believe they will. On 20/12/14 21:52, James Cummings wrote:
On 20/12/14 20:42, Lou Burnard wrote:
I don't understand what you mean James.
I'll try to explain it in more detail then.
I am thinking that there are very likely to be devious pathways through e.g. Manuscriptorium which expect to find @type used in the way our dogma now says you should use @unit. I see no reason to risk confusing such software.
You seem to think that the developers of Manuscriptorium are updating their TEI Enrich schema with every TEI release and are suddenly going to be faced with all sorts of files that do not validate. This is not the case. Their msDesc creating software, M-Tool, is set in stone, it will produce files that will work with their system and validate against the TEI Enrich schema that they have. If indeed they ever validate their files, which I don't know if they do or not. Regardless, I doubt that they will be updating their schema any time soon. People creating files for Manuscriptorium don't go to Roma to generate their own schemas, they either use M-Tool, or use the TEI Enrich schema that Manuscriptorium gives to them. Changing whether something will be valid in a schema at the next TEI release has _no_ effect on running software unless it chooses to update to cope with files from that version of the TEI. There are plenty of people using schemas from TEI P5 1.0.0 and have software built on that which they have not updated. (Yes, they don't get any new goodies, but that is their choice.)
Is that clearer?
Deprecation is all very well, but it's no reason to break Birnbaum!
It isn't. Holding up the Birnbaum Doctrine as some sacred talisman against change for the sake of backwards compatibility just doesn't work any more. http://www.tei-c.org/Activities/Council/Working/tcw09.xml in fact specifies that we *can* deprecate elements and attributes in precisely this way. (It didn't really specify a mechanism to do this, which we created later and documented in http://www.tei-c.org/Activities/Council/Working/tcw27.xml) To repeat, the Birnbaum doctrine suggests deprecation and deprecating one of its suggested ways of dealing with such changes. The tcw27 deprecation mechanism *supersedes* Birnbaum's tcw09 to reflect council's decisions, as it says in tcw09. We made the decisions leading to this deprecation mechanism over a couple years, and it has now been a couple years since we started implementing them. This is not breaking Birnbaum, we redefined the deprecation mechanism of that ages ago.
It will have no effect on those using the TEI Enrich schema because they aren't updating their schemas (or like my Bodley/CUL project are using it as a starting point to create something new). It doesn't break Birnbaum.
Deprecate.
-James