Clarify semantics of attRef

[dmj]

An attList may contain zero or more attRefelements referencing an attribute specification. The attRef has two attributes, @class and @name which are both optional.

https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-attRef.html

This gives four possible variations:

@class	@name	Referenced attDef(s)
no	no	ignore
no	yes	The attribute @name in the current attList
yes	no	All attributes defined in @class
yes	yes	The attribute @name in @class

Observations:

1. The current p5subset does not use attRef at all
2. There should be a ISO Schematron rule for attRef that raises an error if the element has neither the @class nor the @name attribute

[sydb]

Or, perhaps better yet, if we get @org to work properly in atop (it does not in the current Stylesheets):

  <elementSpec xmlns="http://www.tei-c.org/ns/1.0" module="tagdocs" ident="attRef">
    <gloss versionDate="2005-04-13" xml:lang="en">attribute pointer</gloss>
    <!-- ... -->
    <attList org="choice">
      <attList org="group">
    <attDef ident="class" usage="req">
      <desc versionDate="2013-11-16" xml:lang="en">the name of the attribute class</desc>
      <datatype><dataRef key="teidata.name"/></datatype>
    </attDef>
    <attDef ident="name" usage="opt">
      <desc versionDate="2013-11-16" xml:lang="en">the name of the attribute</desc>
      <datatype><dataRef key="teidata.name"/></datatype>
    </attDef>
      </attList>
      <attDef ident="class" usage="opt">
    <desc versionDate="2013-11-16" xml:lang="en">the name of the attribute class</desc>
    <datatype><dataRef key="teidata.name"/></datatype>
      </attDef>
      <attDef ident="name" usage="req">
    <desc versionDate="2013-11-16" xml:lang="en">the name of the attribute</desc>
    <datatype><dataRef key="teidata.name"/></datatype>
      </attDef>
    </attList>
    <!-- ... -->
    <listRef>
      <ptr target="#TDmodules"/>
    </listRef>
  </elementSpec>

[dmj]

Or, perhaps better yet,

How would properly implementing attList solve the missing documentation of attRef?

[dmj]

Okay, @sydb, I get what you are talking about. Still, the ambiguous case is no @class and just a @name: An attList may declare multiple attributes with the same name.

[sydb]

True enough (that just @name is not a good idea). But no, I do not think an <attList> may declare multiple attributes with the same QName. Thoughts:

1. An <attRef> with @name but not @class does not mean the named attribute from this <attList>. I am not actually sure what it means, if anything, but that certainly can’t be right. (Not even Sebastian was that crazy; but as was his usual, this is underspecified.)
2. See #2282.
3. In an ideal world, it would be nice to have a constraint on <attList> that enforces the idea that it may not declare multiple attributes with the same QName. Before we had <attRef> this would not have been difficult to do. If TEI decides that @name is a required attribute of <attRef>, it is still reasonably easy to write.
4. <attRef> has no mechanism to select one attribute over another that has the same local name. That is, given an attribute class definition for att.formalLangIdentifiers that creates an @xml:lang, a @tei:lang, and an @iso:lang, our <attRef> has no way to say which @lang it wants, does it? (We make an exception for xml:*, but in general do not use prefixes to differentiate namespaces, as we do not know what prefix is mapped to which namespace URI.)
5. I think there was a 5th thought, but I am so tired it fell out of my head.

[martindholmes]

@sydb, @HelenaSabel and I consider that using <attRef> to point to a collection of one or more attributes defined in RNG is not really a good idea; instead, there should be another way to do this (<rngRef>?). Unless and until that happens, ATOP need not concern itself with <attRef>s that don't point to ODD-defined entities, and ATOP will require both @name and @class, and we suggest (see https://github.com/TEIC/TEI/issues/2282) that TEI make the same requirement.

[martindholmes]

Closing this: see TEI issue https://github.com/TEIC/TEI/issues/2282, where work is under way. Also https://github.com/TEIC/TEI/issues/2548.