no duplicate `<attDef>`s allowed #2534

sydb · 2024-03-14T20:27:08Z

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.

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

martindholmes · 2024-03-15T03:23:11Z

@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 · 2024-03-15T20:24:59Z

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.

@martindholmes

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.

sydb · 2024-03-15T21:56:13Z

Fixed, and added more tests to detest.

sydb · 2024-03-15T21:57:57Z

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 · 2024-03-16T13:40:05Z

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

@martindholmes

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.

@ebeshero

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

sydb · 2024-04-13T07:10:28Z

Rebased current dev into this branch
Addressed concern about namespace URIs, above
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 · 2024-04-13T12:05:01Z

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

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

…ommit

sydb · 2025-05-18T14:43:02Z

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):

Leave things as they are — users should see the comments on the tagdoc pages. (We might want to make them prettier, though.)
Continue to use the comments in the source, change Stylesheets so that comments within a <constraint> are not reproduced on the tagdoc pages.
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.
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.
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 · 2025-05-19T15:14:33Z

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

ebeshero · 2026-01-04T00:26:07Z

Just updating the comments here: No longer blocked because we resolved the method of excluding comments from the Guidelines output. So we're now testing whether this constraint works to target duplicate <attDef> elements with the same @ident in the same ancestor::attList[not(@choice)] and not in different namespaces. Reminding myself of that, I'll try to test the PR now.

ebeshero

@sydb I've reviewed the code, made a bunch of tiny prose edits on the detest file in GitHub's suggest mode that we can just review and merge in via the web interface. I can verify that this passes tests, doesn't break builds, and when I run exemplars and work with a generated TEI-All schema, it works to validate an ODD with a bunch of different test cases for attributes of the same @ident value with and without namespaces. Looks good to me.

P5/Test/detest.odd

ebeshero · 2026-01-04T07:07:22Z

P5/Source/Specs/attList.xml

+                          preceding-sibling::tei:attDef[
+                            @ident eq $ad/@ident
+                            and
+                            ( @ns, $notanamespace )[1] eq ( $ad/@ns, $notanamespace )[1]


@sydb This part seems a little abstruse, but it's ultimately readable when we see that $notanamespace is just a bit of string. I guess it saves you from having to write an extra set of conditions for namespaced attribute or not, and somehow it makes sense for coping with the situation of the same attribute name with and without a namespace. And I can definitely verify that it works on a test ODD I just wrote.

I'm just committing my suggestions since they're pretty tiny and just prose edits.

sydb added 2 commits March 14, 2024 16:14

Ooops; forgot content of change log entry

220f3ad

sydb added the TEI: ODD label Mar 14, 2024

sydb added this to the Guidelines 4.8.0 milestone Mar 14, 2024

sydb requested review from HelenaSabel, joeytakeda, martinascholger and martindholmes March 14, 2024 20:27

sydb assigned trishaoconnor Mar 14, 2024

sydb marked this pull request as draft March 15, 2024 20:25

sydb marked this pull request as ready for review March 15, 2024 21:53

sydb added 5 commits April 13, 2024 02:54

Ooops; forgot content of change log entry

40a2f2e

fix conflict whose existence I cannot explain

1418059

Address @martindholmes’ concern:

55d0aa4

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

sydb added 6 commits April 25, 2024 15:22

Ooops; forgot content of change log entry

9abe908

Use the latest detest.odd

1e2646f

Trying to force git to use the lateset detest

f78b766

concluding merge

a78709b

Grab latest from dev

56a5bb6

ebeshero modified the milestones: Guidelines 4.10.0 , Guidelines 4.9.0 Jan 23, 2025

After lots of hand checking and a few tweaks, finish merge (of dev) c…

98d8c2c

…ommit

martindholmes mentioned this pull request May 19, 2025

Comments inside Schematron rules should be removed when building documentation TEIC/Stylesheets#746

Closed

HelenaSabel added the Status: Blocked label May 19, 2025

ebeshero modified the milestones: Guidelines 4.10.0, Guidelines 4.11.0 Aug 15, 2025

sydb removed Status: Blocked Status: Pending pending action described in a comment, to return to discussion before further action will be taken labels Jan 3, 2026

Merge completed after manual merging of detest results

5e22a6c

ebeshero self-requested a review January 4, 2026 00:26

ebeshero approved these changes Jan 4, 2026

View reviewed changes

ebeshero added 11 commits January 4, 2026 02:11

Update P5/Test/detest.odd

0cd1d9c

Update P5/Test/detest.odd

e87f02a

Update P5/Test/detest.odd

b3674fa

Update P5/Test/detest.odd

6e939e5

Update P5/Test/detest.odd

8c03d86

Update P5/Test/detest.odd

36612fc

Update P5/Test/detest.odd

34a35af

Update P5/Test/detest.odd

e2dc23f

Update P5/Test/detest.odd

64c6100

Update P5/Test/detest.odd

58320f8

Update P5/Test/detest.odd

9d46360

ebeshero merged commit dce382e into dev Jan 4, 2026
2 checks passed

sydb deleted the sydb_2371 branch January 4, 2026 14:29

no duplicate <attDef>s allowed #2534

no duplicate <attDef>s allowed #2534

Uh oh!

Conversation

sydb commented Mar 14, 2024

Uh oh!

martindholmes commented Mar 15, 2024

Uh oh!

sydb commented Mar 15, 2024

Uh oh!

sydb commented Mar 15, 2024

Uh oh!

sydb commented Mar 15, 2024

Uh oh!

martindholmes commented Mar 16, 2024

Uh oh!

sydb commented Apr 13, 2024

Uh oh!

ebeshero commented Apr 13, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sydb commented May 18, 2025

Uh oh!

sydb commented May 19, 2025

Uh oh!

ebeshero commented Jan 4, 2026

Uh oh!

ebeshero left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ebeshero Jan 4, 2026

Choose a reason for hiding this comment

Uh oh!

ebeshero Jan 4, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

no duplicate `<attDef>`s allowed #2534

no duplicate `<attDef>`s allowed #2534

ebeshero commented Apr 13, 2024 •

edited

Loading