First crack at addressing #2173 in a serious way. #2442
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
@test
in 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.)@context
of 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.)@test
I 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>
.)