branch concern

I am not 100% that I got the branch-management part of this correct. My instinct is that the patch release should be made from the "release-4.10.1" branch, and then it should be merged into the "released" branch (i.e., this PR). But IIRC the actual release procedure is to merge first.

changes made and why

[I told the folks at the meeting this morning that I would test removing only the abstract pattern, rather than removing all 40 concrete instances of that pattern, but that I did not think it would work because Schematron would (quite reasonably) complain that it cannot find the abstract pattern that is instantiated in each of the att.declarable elements.]

Boy, am I an idiot. Or, more likely, I am getting demented.

I tested (by removing the one abstract pattern from P5/Source/Specs/att.declarable.xml), and the build worked! But it should not have worked. You can test this if you want by whipping up a new Schematron schema that has nothing but:

<?xml version="1.0" encoding="UTF-8"?>
<sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron" queryBinding="xslt2">
  
  <sch:pattern is-a="W-P" id="Carnie">
    <sch:rule>
      <sch:param name="Wendy" value="Chynna"/>
    </sch:rule>
  </sch:pattern>
  
</sch:schema>
<!-- Two points to anyone who figures out what “W-P” stand for. :-) -->

If you try to process that with SchXslt for sure, and with any modern Schematron processor I bet, you will get serious errors. Heck, oXygen flags validity errors before you even try to use it! This is because this code says to the processor “go find the pattern with ID "W-P" and execute it, replacing the parameter $Wendy with the value Chynna.”, but when the processor looks for a pattern with ID "W-P" it cannot find one.

So why was there no error in our build process? Because less than 3 months ago we updated our Stylesheets so as to drop concrete instances of abstract patterns when the abstract pattern is missing (see TEIC/Stylesheets#751). That is, when our Stylesheets find a Schematron pattern in p5.xml (or p5subset.xml) that has an @is-a, they check to see if there is a corresponding abstract pattern; if there is NOT such an abstract pattern, the pattern with the @is-a is NOT copied over to the output schema.

That is to say ~3 months ago we wrote code for the Stylesheets that anticipated this exact situation, and does the right thing. The embarrassing bit is that I was the one who did that! Sigh.

addendum, not really pertinent to the actual change to TEI

We originally thought I was going to have to modify all 40 specifications for the elements that are members of att.declarable. I asserted at the meeting (some might say bragged) that I would probably do this using an Emacs macro, so I could do it “using only one keystroke” per file. Others at the meeting, perhaps a bit dubious, wanted me to post the macro, so here it is:

(setq last-kbd-macro
   (kmacro "M-< C-s SPC i s - a = \" <right> C-r < c o n s t r a i n t S p e c C-a C-SPC C-s < / c o n s t r a i n t S p e c C-e <right> M-x c o m m e n t - r e g i <tab> <return>"))

That macro deserve a little annotation:

• M-< = goto top of file (probably not needed, as files open to the top by default, but just in case …)
• C-s SPC i s - a = \" = incremental search (forward) for the string “ is-a="” (which will never occur except in a concrete instantiation of an abstract pattern)
• <right> = move cursor one character to the right (not really important, but cancels the incremental search — if I had thought ahead I might have done a regular search instead, but the result is the same)
• C-r < c o … p e c = incremental search (backward) for the string “<constraintSpec”
• C-a = move cursor to the beginning of the line (which is now the line that has “<constraintSpec”)
• C-SPC remember this spot (i.e., remember the current cursor position)
• C-s < / c … p e c = incremental search (forward) for the string “</constraintSpec”
• C-e = move cursor to the end of the line (which is now the line that has “</constraintSpec”)
• <right> = move cursor one character to the right (which puts it at 1st char of line after end-constraintSpec tag)
• M-x c o m … e g i <tab> <return> = issue the command comment-region which comments out all lines between the spot that was remembered and the place the cursor is currently

And presto! Just by typing C-x e (which means “execute last keyboard macro”) it (the problematic <constraintDecl>) is commented out. Setting up this macro took around 1 minute.

The observant among you will notice that this would not work if there were other tags on the same lines as <constraintSpec and </constraintSpec. Luckily there are not. You also might say “but that is 2 keystrokes, Syd, C-x and e”. And, in some sense, that is a valid complaint. But IIRC the Emacs manual calls the entire combination a single keystroke. (The C-x part is differentiated as a "prefix".)