-
Notifications
You must be signed in to change notification settings - Fork 84
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
no duplicate <attDef>
s allowed
#2534
base: dev
Are you sure you want to change the base?
Conversation
that flags as an error any 2+ attDef elements who both share an ancestor attList and have the same ident= attribute (regardless of the mode= attr value) unless they are both (all) children of an attList that has an org= attribute value of "choice".
@sydb Does this take account of namespaces? You could correctly have two atts with the same |
No, it does not. For some reason I guess I thought we had decided to look at only |
Per suggestion @martindholmes, make sure to think of two attributes that have the same local name (i.e., ident= attribute) but different namespaces (i.e., ns= attribute); since the attList element does not have an ns= attribute, we do not have to worry about inheritance, which makes this much easier.
Fixed, and added more tests to detest. |
One possible concern is that the comments I put in the Schematron show up in the Guidelines. Some folks will like that, others won’t. |
@sydb I know you will think this is trivial, but I don't think we should use YouTube URLs as spurious namespaces in tests. I don't think it's polite to commandeer someone else's domain for this sort of purpose, and I would also be concerned that any controversy or conflict arising in relation to one of these URLs in future might draw the TEI into something it has no connection with. I would prefer to use something like http://www.tei-c.org.ns/test/eg1, 2, 3 and so on. If you have no strong preference for keeping these YouTube URLs, I'll happily add a fix to the PR for this. |
that flags as an error any 2+ attDef elements who both share an ancestor attList and have the same ident= attribute (regardless of the mode= attr value) unless they are both (all) children of an attList that has an org= attribute value of "choice".
Per suggestion @martindholmes, make sure to think of two attributes that have the same local name (i.e., ident= attribute) but different namespaces (i.e., ns= attribute); since the attList element does not have an ns= attribute, we do not have to worry about inheritance, which makes this much easier.
Per suggestion @ebeshero use a different host for easter egg namespace URIs. Also required update to expected results to match new formatting of Schematron msgs. (Not sure why that change wasn’t already present.)
|
@martindholmes Our VF2F subgroup agreed, and our suggestion was just to make up a portmanteau URL, like |
that flags as an error any 2+ attDef elements who both share an ancestor attList and have the same ident= attribute (regardless of the mode= attr value) unless they are both (all) children of an attList that has an org= attribute value of "choice".
description and some comments of new no_duplicate_attrs constraint; change attr names to reflect NameSpace + IDENTifier combination
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.
Apologies for being slow on this. I keep looking at the Schematron rule and realising that I don't quite understand it, and I need to go away and write some specific tests. I don't get what the notanamespace thing is doing.
I think the reason $notanamespace exists is because I wanted to compare Either way, though, on reading it now, since the comparisons are done separately (not combined as in para above), we might be able to get away without the $notanamespace. But I tried removing the $notanamespace bit and just comparing If I were actually writing XSLT I would probably do this in multiple steps. First take $defs (the sequence of all |
Address #2371 with a Schematron constraint that flags as an error any 2+
<attDef>
s that both share an ancestor<attList>
and have the same@ident
(regardless of the@mode
) unless they are both (all) children of an<attList>
that has an@org
attribute value of "choice".The file detest.odd has been updated to test this reasonably well.
If tests pass, I personally do not think any deprecation period is necessary. (What would it deprecate, anyway?) The error this new constraint catches is an error.
Reviewers: If you actually look at the code differences the most important bit (by far) to look at is the new lines 24–76 (in green) of attList.xml.