sydb
commented
9 months ago This PR will probably never be needed, as we expect Council to simply require @context in all cases of <sch:assert> or <sch:report> within a <constraint>.
But some of the work here may be useful. So we should kill this PR when the above has been done.
sabineseifert
Holy smoke. This has been a lot of work.
Branch name is “sydb_2173”. It builds on my local system (in a docker container), and passes the tests established on the ticket. Only possible problem I have noticed is the "unique_xmlIDs" constraint of tei_customization is not contextualizable. That is on purpose, of course. The current Stylesheets generate
"@xml:id"as the value of@context, thus firing on all occurrences of@xml:id(whether the element it appears on got it via att.global or not), which is the desired effect. If necessary we can just add an<sch:rule context="@xml:id">wrapper. (It would be added in P5/Utilities/TEI-to-tei_customization.xslt, around line 1465.)Things I had to do to make this (putting the constraint demonstrated in the ODD attached to the ticket into constraintSpec.xml) work follow, not in any particular order.
@testin the new "context_for_constraint" constraint (the major complex one — “I am inside a<specGrp>”, “and there are one or more references to one or more of my<scpecGrp>ancestors” …) I added a clause to exclude cases of<elementSpec>inside<specGrp>. (There are 47 such cases in the Guideliens.)@contextof the<sch:rule>so it is not fired if the<constraintSpec>is a descendant of an<egXML>. (This is only necessary because of how the build process does testing, I think. If you look at p5examples.isosch.xsl (very carefully) you will find that thetei:prefix is bound to the Examples namespace.)@testI changed “don't” to “don’t” (i.e., U+0027 → U+2019), because the U+0027 caused Utilities/iso_dsdl_include.xsl to mis-count the parentheses, and thus broke the build.<sch:ns>.)