Repository navigation
can't add mode="replace" to attribute class #370
Description
Trying to make changes for TEIC/TEI#1867. This works for the one element, <constraintSpec> which has@mode="replace" and '@mode="change" seems to work for several other elements. but compile fails when new class is added and attribute definition is given `mode="replace".
Activity
sydb commentedon Apr 19, 2019
That is, specifying
mode="replace"on an<attDef ident="type">inside a<classSpec>when the class itself is also a member of att.typed (and thus already had@type) causes a build failure:It shouldn’t.
martindholmes commentedon Apr 19, 2019
@sydb and @martindholmes have narrowed down the problem to what's happening in the odds/classatts.xsl file, where some clever processing takes place to handle cases where attDefs in elementSpecs override those inherited from classSpecs of which the elementSpec is a member. This process is not done for classSpecs (yet). Simply editing the match attribute to cause classSpecs to be processed as well as elementSpecs fails because it generates another kind of error, whereby nested attribute classes end up duplicated on elements, so that simple fix doesn't work. However we think that it is possible to fix this by passing classSpecs through the same process, with some modification to the process.
martindholmes commentedon Jun 21, 2019
@sydb and @martindholmes went back through the commits and tested the build, and determined that the problem was introduced by the merge at #343; that particular merge contains lots of individual commits, but only one file seems to have been changed:
https://github.com/TEIC/Stylesheets/pull/343/files
sydb commentedon Jun 21, 2019
Stylesheets group comes up w/ the following replacement for a template in odds/odd2odd.xsl:
martindholmes commentedon Jun 21, 2019
The above function didn't actually work, but subsequent tests show that the problem with simplePrint is that it consists initially only of specGrpRefs, and those refs are not expanded early enough in the process. So we need a pass before pass0 which will expand all specGrpRefs.
ebeshero commentedon Jun 21, 2019
Quick summary of where we stopped the meeting: We were constructing a variable as a document-node() with guidance from the Kay book, to store the expanded specGrpRefs and pass them to the
key()definition as its third argument, which defines its context and must be a document-node. This will, we hope, give us a means to do a pass before pass0!sydb commentedon Jun 22, 2019
Do tell, @ebeshero, y’all are talking about using the XSLT 2.0
<xsl:document>instruction, yes? That’s where my head is going right now. I played with it — dividing pass0 into two passes — for perhaps half an hour this morning. But I am no longer convinced this is a stylesheets bug!I think it may be a tei_simplePrint problem. Namely, that it (P5/Exemplars/tei_simplePrint.odd) has two
<classSpec type="atts" ident="att.global.rendition" mode="change">elements. Is that supposed to be allowed?My instinct is “yes, someday we would love it if multiple
mode=changedeclarations worked, but it doesn’t now and hasn’t for the last decade, so use only one.” Well, at least that’s what I vaguely recall saying in workshops. But it was working just a few months ago, eh? Or was that second<classSpec>added? @martindholmes do you remember? If not, I will try to look that up again later today.Anyway, if validated against P5/Exemplars/tei_customization.isosch, this duplicate
<classSpec>is not caught, but 4 duplicate<elementSpec>s are. (As well as 4 duplicate@xml:idvalues, and a bunch of stuff that should not really be a problem.) The error messages are “Current ODD processors will not correctly handle more than one ＜elementSpec＞ with the same @Ident” on lines 3430, 4646, 4982, and 5113.sydb commentedon Jun 22, 2019
Oh, but that’s silly, isn’t it — this ticket is about mode="replace" in attribute classes other than simplePrint. We were just using simplePrint as a test case yesterday. (Possibly a red-herring test case, though.)
martindholmes commentedon Jun 22, 2019
We should definitely fix simplePrint, and add some Schematron to prevent this duplication. It makes no sense in a single ODD file.
martindholmes commentedon Jun 28, 2019
@sydb and @martindholmes have added fixes (TEIC/TEI/#6589fca) (along with @lb42 ) to simplePrint to avoid cases where there are multiple *Spec elements with the same
@ident. This should fix the build process for the moment.lb42 commentedon Jun 29, 2019
This change does cause the make to fail a little further on: something is apparently going wrong in the generation of the -examples.rng file, or the nvdl file which calls it. I can't reproduce the problem using the current "bleeding edge" framework in oXygen, which obstinately goes on doing the right thing, so I am still puzzled.
lb42 commentedon Jun 29, 2019
On closer inspection, these are all genuine errors, or at least discrepancies between what the prose of the TEI Simple doc says is possible, or exemplifies, and what the schema supports.
I've opened a separate ticket for that at #383 (and closed it again, having fixed the problems)
7 remaining items
sydb commentedon Nov 20, 2023
Assigning to @trishaoconnor for the purpose of testing to see what is left to do on this ticket. Quick survey seems to say that the main remaining problem is the HTML output of the test ODD does not correctly reflect that the attribute (
@typein this case) has been over-ridden.trishaoconnor commentedon Mar 7, 2024
Tested this with @sydb and the results indicated that the schema is correct but the HTML output does not reflect that
@typewas replaced.ebeshero commentedon Jul 7, 2024
Revisiting this, I think we have several unresolved tickets that might(?) now be resolved with changes in ODD processing. I think we might want to collect them in a bundle and determine where we are with each reported issue. @emylonas Is this ODD still part of your world? I wonder if we can try it again...