-
Notifications
You must be signed in to change notification settings - Fork 96
First crack at addressing #2173 in a serious way. #2442
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: dev
Are you sure you want to change the base?
Conversation
|
This PR will probably never be needed, as we expect Council to simply require |
| if (@ident) | ||
| then concat('("', @ident,'")') | ||
| else ''"/> has no @context, but is in a specGrp that has at | ||
| least 1 reference to it that is not contextulizable.</sch:report> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo: contextulizable (missing "a") and I would spell out 1 to "one"
|
Full Council discussion at VF2F 16 March 2024:
|
|
@sydb The Council decision in 2024 says this PR should be closed. Do you agree? |
martindholmes
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Judging by the discussion, this PR should just be closed since it's no longer needed.
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>.)