no duplicate <attDef>s allowed

[sydb]

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.

[martindholmes]

@sydb Does this take account of namespaces? You could correctly have two atts with the same @ident but in different namespaces, no? Forgive me if I've missed it; I'm reading on my phone.

[sydb]

No, it does not. For some reason I guess I thought we had decided to look at only @ident (not +@ns), but that would be silly.
Will try to fix v. soon.

[sydb]

Fixed, and added more tests to detest.

[sydb]

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.

[martindholmes]

@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.

[sydb]

1. Rebased current dev into this branch
2. Addressed concern about namespace URIs, above
3. Tested, passes all tests on my local system (except NVDL and XeLaTeX do not work on my system, so are untested). Only error is the 3 <superEntry> warnings that have nothing to do with this PR.

[ebeshero]

@martindholmes Our VF2F subgroup agreed, and our suggestion was just to make up a portmanteau URL, likehttps://teitube.org or some such. Re-reading now, your ns suggestion is probably more befitting to the task.

[martindholmes]

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.

[sydb]

I think the reason $notanamespace exists is because I wanted to compare @ns eq $ad/@ns. I was either worried that it was not legal to perform the comparison if one or both did not exist, or I was worried that if @ns is "ab" and @ident is "br", then just comparing @ns||@ident would erroneously succeed when $ad/@ns was missing and $ad/@ident is "abbr".

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 @ns eq $ad/@ns, and the tests fail because in "no_duplicate_attrs_2_valid" the attribute definition for @fun is incorrectly flagged as a duplicate. (It is not a duplicate because it is in an alternation, i.e. its parent <attList> has org="choice".)

If I were actually writing XSLT I would probably do this in multiple steps. First take $defs (the sequence of all <attDef> descendants) and generate a sequence that, for each one, is the namespace & ident in Q-notation. Then a) all comparisons are just simple string comparisons and b) it is easy to generate Q-notation output. But I am not sure that is reasonable to do in Schematron alone.

[ebeshero]

Reviewing this aging PR, I'm wondering what remains to do here once we update the branch? I hope we resolve this for the next release!

[sydb]

OK. We really should not have let this fester for 11 months. (I take much of the blame for that, BTW.) Made it quite difficult to bring it up to date with current dev branch and to figure out what the BLEEP is being done. Luckily, I left reasonably detailed comments.

They are, however, the problem. That is, I think this branch is ready to go, except for the issue of the comments. It still requires review and testing, of course, this is complicated stuff.

But the comments require a decision by Council.

This is some pretty complicated Schematron code. (I suspect, but do not know, that it would be somewhat simpler using the upcoming next version of Schematron, but I do not think it would be simple enough that anything in this discussion about comments would be different.) The good news is the comments therein make it somewhat easier to understand. The bad news is those comments get reproduced in the HTML output of the Guidelines. Some folks do not think the comments should be there.

Possible ways to address this concern (in a numbered list just so we can refer to them, no order of preference implied, as I have not made up my mind):

1. Leave things as they are — users should see the comments on the tagdoc pages. (We might want to make them prettier, though.)
2. Continue to use the comments in the source, change Stylesheets so that comments within a <constraint> are not reproduced on the tagdoc pages.
3. Remove the comments from the source. In which case, we probably want to add a big block comment outside the <constraint> that tries to explain what is going on in there. This makes both writing and using the comments somewhat harder, but does solve the problem.
4. Change the Stylesheets so that comments within a <constraint> are not reproduced on the tagdoc pages, and then start using the <sch:p> element to document things inside a <constraint> when we do want the documentation to show up in the tagdoc page. NOTE: OXygen says the <sch:p> element is valid; our schema says it is not. So we would have to investigate and fix that, first.
5. Invent a mechanism to allow the ODD author to say whether any particular comment should show up in the output or not. (E.g., a <tei:comment> element with an @includeInDocumentation attribute.)

[sydb]

Council decides this PR is blocked awaiting TEIC/Stylesheets#746.