#754 Need for a standard way to warn of class changes affecting ODDs

[Martin Holmes]

The recent restructuring which caused @rend, @style and @rendition to be moved from att.global to att.global.rendition has inevitably caused some confusion as previously-working ODDs generate invalid schemas when processed against the latest P5 source.

Since this is a scenario that is likely to happen again, it would be a good idea to devise and document a standard method of warning against this; obviously Schematron would be useful, but it's not clear where the best place to put it might be, and there are probably other mitigating actions we can carry out leading up to and following such a change which would warn people.

[Sebastian Rahtz]

the short answer is surely "dont do changes like this when Birnbaum doesnt justify it" :-}

it would be possible to catch this particular thing in the ODD processing XSL, as its going to bite many people. i.e. using pre-processing and issuing a warning.

[Martin Holmes]

That's a bit OTT. We're in a situation, then, in which no-one wants to talk about P6 because that has to wait for a game-changing platform shift such as moving away from XML; but neither are we allowed to make improvements to the current P5 which affect backward compatibility even slightly. A better recipe for moribundity and stagnation could hardly be devised.

In any case, this particular change doesn't affect backward compatibility in the way we normally define it: TEI documents which were valid against previous versions of p5_all are still valid against the new version of p5_all, and ODD files which were previously valid are still valid. It's just that processing old ODD files against the new source will cause a problem. We've done this before (moving attributes from one class to another), and I'm sure we'll do it again; we just need to find the best approach to minimizing confusion and helping users who encounter the change. I'm sure that's not beyond our capabilities.

[Martin Holmes]

On the second bit: It's certainly tempting, but I would be a bit reluctant to build special cases like this into the ODD processing, because that's supposed to be something that could be implemented by anyone on any platform, for any flavour of ODD, not just TEI.

[Sebastian Rahtz]

Practically, i don't think we can get Schematron or anything in place in time to provide mediation for the problem as it stands. I'd have thought an information campaign on maillist lists, and a news item, and tweets etc is as good a solution as any.

As regards P6, the TEI needs an infrastructure to support non-backwards-compatible releases, using a forking mechanism. Its going to be quite tedious to set up a complete parallel working setup, but i would suggest its worthwhile to get the mechanism in place.

[Martin Holmes]

Council 2015-05-29: Subgroup suggests closing this because there's no clear course of action we could take. The actual original bug is fixed.

[Syd Bauman]

I disagree (with closing this ticket). I’m not sure we can improve much on the particular problem of changing the class of an attr, but we can improve on lots of similar problems quite easily by including odd4odds as an Exemplar. Since it gets built at P5 build-time, it knows things like what elements are available in what modules (and thus, e.g., complains on <module key="teiHeader" except="div1">).

Oh — but I just realized that particular problem is the name of this ticket. So maybe this one should be closed and a new one opened. (On the other hand, maybe odd4odds can make that test … I’ll have to check, but can’t do that right now.)

And, of course, we’d want odd4odds seriously updated to better reflect PureODD.