Better explain the use of attributes that do the same thing

[joeytakeda]

This arises out of the #2653, which adapted the remark for @key and @ref to discourage the simultaneous use of @ed and @edRef. I'm wondering if we should have a principled approach -- or at least some better discussion -- of these kinds of attributes: attributes that do more-or-less the same thing, but one points specifically at a thing and one uses a token.

A non-comprehensive list of these (from a quick look through Appendix D):

• @ed and @edRef
• @key and @ref
• @rend and @rendition
• @lemma and @lemmaRef
• @script and @scriptRef
• @scribe and @scribeRef
• @unit and @unitRef

By and large, the guidance has been "We don't know what it means if both are used, but if you want to use both, then document what it means to you," but how this has been expressed varies: sometimes using schematron, sometimes remarks, and sometimes saying nothing at all.

Of course, these may not all be the same kind of thing, but for ones that are, it would be nice to have some sort of broad guidance about these kinds of attributes (and possible some sort of term for the kinds of pairings, but I can't think of a nice name for them) that outlines why the GLs have both, that the GLs have no real guidance about what it means to use both, and some guidelines about how encoders ought to document it if they decide to use both.

[jamescummings]

I would add to your list by suggesting that with rend&rendition there is also the style attribute. I'd take a harder line and say that in customising the TEI it is the obligation of those doing so to do certain things. Decide between ed and edRef, between rend/style/rendition, between key and ref, to give value lists for any teidata.enumerated attribute that doesn't have a valList, etc. TEI customisations Which don't do this and more aren't non-confirmant, just not as finished as they should be. ;-)

Where there is a choice between a URI-based attribute and a magic token meaningful only to the project, I'm off the opinion that the former should be preferred by protects unless they have good reason not to. Call me a pointing purist. ;-)

(I am, of course, also a complete hypocrite!)

[HelenaSabel]

Overview

• @ed and @edRef (att.edition): definition clear, remark about use
• @key and @ref (att.canonical): definition remarks (same as @ed and @edRef and a specific one) about use
• @rend and @rendition (att.rendition): missing general remark, definition clear and individual remarks. Proposal: add remarks to the class.
• @lemma and @lemmaRef (att.linguistic): missing general remark
• @script and @scriptRef (att.handFeatures): remark saying that you don’t usually both. Proposal: change remark
• @scribe and @scribeRef (att.handFeatures): remark saying that you don’t usually both. Proposal: change remark
• @unit and @unitRef (att.measurement): schematron informing of how you don’t usually want to use both.

Proposal (Group A, F2F 2025, Kraków):

1. to class att.rendition add general remark that combines the individual remarks of each attribute
2. to @lemma and @lemmaRef: add general remark (the one used for @ed and @edRef)
3. to class att.handFeatures: replace current remark with the one used for @ed and @edRef
4. to @unit and @unitRef: add general remark (the one used for @ed and @edRef)
5. either we add the schematron to all of them or we replace the schematron from att.measurement

[raffazizzi]

F2F approves these proposals with a change in att.rendition:

• move the remarks from individual attributes to the class, as proposed
• remove the remark about @rend overriding @rendition
• introduce the same remark as others, saying that if you're using @rend and @rendition together you should explain how.

Also replace schematron in att.measurement with a general remark.