-
Notifications
You must be signed in to change notification settings - Fork 125
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
multiple <anyElement>
results in invalid RELAX NG schema
#631
Comments
@sydb How does the ATOP PLODD processing do on this? Same problem? |
Did not even look. But no reason to think it has same problem, as code base is entirely different. |
I have submitted a PR that I believe fixes this bug. It is like solution (3) proposed above, but I used I found this very hard to do (it took the better part of 2 days) in large part because I took some less-than-brilliant paths and detours, but also in large part because it turns out that code that generates |
… untested because of #631. This comit is *not* ready for prime time.
Separate pattern for every instance of <anyElement> — fixes #631 (I hope)
Another bug that has probably been around for years if not decades and never been noticed. If you have more than 1
<anyElement>
in a content model the resulting RELAX NG is invalid.I will post an ODD file (bundled with the output of
teitorelaxng
(soon to beteitorng
) run on that ODD, as Github makes me ZIP it, anyway) that demonstrates the problem on this ticket shortly.I think the problem is entirely contained in odd2relax.xsl. It generates an
<rng:define>
for each<anyElement>
that occurs in the compiled ODD input. Then, in the cleanup phase (in "pass3"), I think it tries to delete some of the<rng:define>
s that have just been created — presumably all but one. But in this case it deletes them all.This is some very convoluted, uncommented code. I am still trying to wrap my head around the "max( ancestor::rng:div )" part. An
<rng:div>
has no effect on validation, so why is it important to delete only the<rng:define>
that is most deeply nested in<rng:div>
s, and how does that ensure there is only 1 resulting<rng:define>
?In any case, this problem is sort of blocking progress on #627, not because it is interfering with writing the code for fixing #627, but because it makes it a pain in the neck to test said code.
Several possible solutions jump to mind, but until I understand at least what the current Stylesheets are doing, better still why, I doubt I could really endorse any of them, let alone one over the others:
<rng:define>
s for the given pattern, then put one back<rng:define>
per<anyElement>
-inside-given-<elementSpec>
-or-<macroSpec>
is generated in the first place. (This should not be hard to do — change//tei:anyElement
to//*[tei:anyElement]
in both places, and change template "anyElement" to match. But who knows what else that might break? Might be a problem because different occurrences of<anyElement>
in the same content model might have different@require
or@except
, no?)<rng:define>
with a different pattern name is generated for each and every occurrence of<anyElement>
. (This should not be hard to do — change definition of $id in "anyElement" template fromconcat('anyElement-',$spec/@ident)
toconcat('anyElement-', generate-id() )
. But changing the references to each such pattern might be hard; probably not, but I am nto sure. And in any case, who knows what else that might break?)OK, having written that out long hand I take back my previous statement about not knowing which is best. Seems to me at the moment that (3) is probably the only viable solution. Otherwise how would different
@require
and@except
values in the same content model work?BTW, I may well continue work on #627 (since it is causing problems for the WWP) first, even with convoluted testing procedures, before paying more attention to this. Thus I have not assigned this issue to a milestone.
The text was updated successfully, but these errors were encountered: