TEIC
Should mode attributes cascade?
In dealing with #393, Stylesheets group discovers that we must specify a @mode attribute on everything being changed (including attDef, on which we don't always customarily use mode attributes). Right now if you want to remove a default value you have to apply @mode='change' to the parent attDef (for example, as shown in #393), in order to derive a working RNG schema. We're not sure this should be required. There's a general principle we need to decide on: Should we establish inheritance of mode when specified on an ancestor element, or should we mandate (and make Schematron) to use mode everywhere?
Related issues may be:
#237
#370
@sydb and I, testing some scenarios, discovered that if you have an elementSpec in your ODD with the same ident as a TEI element, but you don't give it @mode OR you give it @mode="add", then the effect is to delete (not replace or change) the original TEI elements, irrespective of the contents of the elementSpec in your ODD. This we believe is just wrong. In this sense, the Stylesheets behave as though the default value of @mode is "delete".
The behaviour for attributes is different but also pernicious. If you have @mode="change" on the elementSpec, and then you provide <attDef>s with either @mode="add" or with no @mode attribute, the effect is to end up with two definitions of the attribute, giving you a broken schema.
In the interim, @martindholmes and I just decided that tei_customization should test that IF an <elementSpec>’s @ident and @module say it is from the TEI scheme (or, alternatively, there is no @ns to say otherwise), THEN its @mode should NOT be "add".
I expect to work on adding this constraint this evening.
BTW, that change was made yesterday or day before in TEI repo commit 6e02622. Mr. Jenkins has not complained.
@sydb and @martindholmes suggest that we dub the first problem (the assumption that the default mode is "delete" on elementSpecs) as 402a, and the second one (the production of duplicate attributes in the output schema) as 402b. We expect the Stylesheets group meeting in December to address these.
We suggest that in the case of 402a, the right behaviour for the Stylesheets is not to try and guess what you might have meant by an <elementSpec> with no @mode, but to stop with an error saying that the ODD is ambiguous in this respect, and @mode should be added. If the Stylesheets group agree, we could add that to the processing relatively easily.
Stylesheets group says we need to write a test ODD for these two error types before working on this again.
And the ODD that Syd wrote for #393 might be adapted to be a test ODD for this issue.
Someone needs to test what happens now with a simple ODD with removing default values. Is the behavior what we expect?
@sydb Here's a ticket that got lost in my pile, but I'm wondering how it will fare in today's 2024 ODD processing...