TEIC
classRef in oddtoodd assumes the class concerned is not locally defined
A classRef in an ODD usually references a classSpec provided in the @source resource specified, typically p5subset.xml. However, there's no reason why the classSpec and the classRef shouldn't both be in the same source, except that odd2odd will raise an error if this is so. The template starting at line 618 should perhaps be modified to generate a warning for this scenario instead, since it seems plausible (if mad) for example to define a class supplying three attribute and then decide you only want to use two of them.
here's a testfile:
(and isnt it a pain that I cant upload an xml file without zipping it first)
I've just looked at your test file and understood something for the first time: As the original classSpec and the classRef that modifies it are in the same file, there are legitimately two competing definitions of the class in the same document, and no rules (that I'm aware of) to specify which should be preferred by the ODD processor. Is it possibly the case that this is a specification issue rather than a processing one?
If we say that (for example) any classRef which follows a classSpec in document order overrides it, that means it's impossible for any element to claim membership of the original class (with all three atts) rather than the modified one (with only two). That makes the original definition useless to anyone, and therefore there is no point in first creating it and then modifying it; you might as well modify the original.
Or am I misunderstanding something here? What was your original use-case?
I don't think document order is relevant. The ODD processor always has to reconcile multiple declarations/references irrespective of order. I agree with you that the use case seems a bit unlikely (I said "mad") but it did come up IRL (see discussion with Benjamin Bohl on 2017-01-20 on TEI-L). Imagine that you have a bunch of classSpecs that you want to use in a bunch of different schemas. Imagine further that you don't grock the use of @source, so you keep your library of classSpecs in a file which you then xInclude in each ODD, but follow with a classRef that redefines them.
I hadn't considered the use of XInclude as opposed to @source; that does make sense. In that case we need a rule, but it needs some thought. What if you have two classRefs alongside each other, each modifying the original classSpec in a different way?
The odd processor has to try to resolve the situation as best it can. But that is always true. If you had two class refs and no class spec for example.
That's what I'm saying: when the ODD processor has to make some kind of decision, we need to specify what decision it should make. At the moment, the decision it appears to make is that where a classRef modifies a classSpec in the same file, thus providing two competing definitions of the same class in the same file, it prefers the original one. That doesn't seem unreasonable to me, given the choices available. If you think we should specify something else, then we have to specify it, and then implement it in the processor. If document order is not regarded, then what other criteria should the processor use to decide between the competing definitions?
At the moment that isn't what happens: at the moment it's an error condition to provide a classRef and a classSpec in the same file. I am arguing that it might be plausible to allow for both. If you accept that it might be plausible, we have to agree on what it means. My first thought was that the same kind of unification process as happens when other specifications get duplicated should apply here. A classRef is just a proxy for a classSpec (classCopy would have been a better name for it really), so in my example the ODD processor has to reconcile two specifications for att.xy, one with one attribute, one with two. In other situations, when there are two elementSpecs for example, there is a @mode attribute which explains how to combine them. Here there is no @mode attribute, which complicates things, perhaps to such an extent that we should just not allow it to happen. But it might be argued that the classRef with a restriction (an @include or @except) should win, since it is clearly attempting to modify a pre-existing definition.
OK, so the choice is between:
- Error condition: two competing definitions of the class in the same file cannot hold.
- Precedence to the original classSpec, for the same reason as #1, but not failing.
- Precedence to modifying classRef version; but what if there are multiple modifying classRefs?