I don't understand what you mean James. 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. Deprecation is all very well, but it's no reason to break Birnbaum! On 20/12/14 20:37, James Cummings wrote:

I don't think us changing @type to @unit will cause any of the software you are thinking about to break (a they are unlikely to be generating new schemas)

I suggest changing it.

There are live projects and libraries using it, including a collaboration between Bodley and CUL spec coll developing a modified version of it as we speak for their medieval MSS. But this is the effect if deprecation.

James

-- Dr James Cummings, (from phone) james.cummings@it.ox.ac.uk IT Services, University of Oxford.

-----Original Message----- From: Lou Burnard [lou.burnard@retired.ox.ac.uk] Received: Saturday, 20 Dec 2014, 19:50 To: tei-council@lists.tei-c.org [tei-council@lists.tei-c.org] Subject: [tei-council] Enrich: (was Re: they come to bite us: biblScope/@type fallout

I'm not sure I agree with that. There is quite a lot of data out there in the real world using Enrich and we wont win any friends by breaking it all for no good reason. I think it would be better to add @type as an explicit locally-defined attribute in the enrich ODD.

There is also, I suspect, software which we really don't want to force people to modify., especially since we are no longer in touch with its developers.

On 19/12/14 12:55, Sebastian Rahtz wrote:

...

...

On 19 Dec 2014, at 12:50, Martin Holmes wrote:

Hi all,

Following the removal of biblScope/@type, P5-Test and P5-Documentation built OK, but the main build failed because of the ENRICH schema, which I know nothing about. I guess we have two options: customize the ENRICH schema to add back @type on <biblScope>, or modify ENRICH so that it uses @unit instead.

Since ENRICH seems to be an interchange format, the former seems the better option, so I'll proceed on that basis; if you know differently, please shout. It looks like Lou was heavily involved in ENRICH:

http://projects.oucs.ox.ac.uk/ENRICH/Deliverables/referenceManual_en.html

If the project is still very active, and has some method of discussing and propagating change, we could suggest that they incorporate this change into their schema through whatever mechanisms they usually use. Lou, James and I all worked on ENRICH. No, it doesn’t have an active group any more.

I’d be inclined to the "modify ENRICH so that it uses @unit instead” method, as I don’t want ENRICH to be something other than a subset of TEI. but I’d like to hear what James and Lou think before you do anything. -- Sebastian Rahtz Director (Research) of Academic IT University of Oxford IT Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

Não sou nada. Nunca serei nada. Não posso querer ser nada. À parte isso, tenho em mim todos os sonhos do mundo.

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

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.

One of the design goals for ENRICH was to be a subset of TEI, so I believe that in lieu of any other mandate we should continue making it so, if we want to continue with supporting it. The most honest thing to do might be to remove it from the Exemplars :-} I vote for either dropping it, for keeping it in line with TEI. I do understand Lou’s worry that it will simply annoy people, but I think that updating it is the lesser of two evils. Legalistically speaking, the thing has 3 authors, of whom 2/3 vote to change it. But if you still feel strongly, Lou, how about you consult a known relevant party, viz M Driscoll, and see which way he’d vote? Sebastian

Hi Lou, I'm not sure Mr Driscoll would be horrified; we can only know by asking. As far as "I told you so" is concerned, of course you're at liberty to do that, but the question is: about what? About the move from @type to @unit? About the decision to deprecate this particular use of @type? About the decision not to add <biblScope> to att.typed as a backward-compatibility measure? About the decision to act on the deprecation we have advertised in red in the Guidelines for two years? Cheers, Martin On 14-12-21 06:25 AM, Lou Burnard wrote:

On 20/12/14 23:17, Sebastian Rahtz wrote:

...

One of the design goals for ENRICH was to be a subset of TEI, so I believe that in lieu of any other mandate we should continue making it so, if we want to continue with supporting it. The most honest thing to do might be to remove it from the Exemplars :-}

That would seem to imply abandoning that particular design goal ?

...

I vote for either dropping it, for keeping it in line with TEI. I do understand Lou’s worry that it will simply annoy people, but I think that updating it is the lesser of two evils.

There are quite a few Exemplars which I think are closer to being useless than this one, so I'd not vote for removing it. So I suppose the exemplar needs to be tweaked to be TEI-conformant. Looking into doing that now.

...

Legalistically speaking, the thing has 3 authors, of whom 2/3 vote to change it. But if you still feel strongly, Lou, how about you consult a known relevant party, viz M Driscoll, and see which way he’d vote?

He'd be horrified, but I don't see how that would help. Never mind, I've been outvoted before and doubtless will be again. Just allow me to say "told you so" when the time comes (cf. James on global @resp)

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