attributes of `<attRef>`

[sydb]

[With great thanks to @dmj for bringing this up.]

The <attRef> element has both a @class attribute and a @name attribute. The Guidelines make pretty clear (by example) what an <attRef> that has both of these attributes means. But the Guidelines do not address what an <attRef> with only 1 of those attributes means (if anything), nor an <attRef> with neither (which is essentially nonsensical).

My instinct, without having thought about it much, is that both of these attributes should be required, not optional.

[sydb]

@bleekere & I have assigned this to @martinascholger to ensure the topic is on the agenda of an upcoming Council meeting.

[sydb]

Addendum

The definition of <attRef> is “points to the definition of an attribute or group of attributes”. How does it go about pointing to a group of attributes? All 2 examples in the Guidelines show it pointing to a single attribute.

My first thought is that the answer cannot really be “If it refers to an attribute class with its @class attribute, but does not have an @name attribute, then all the attributes from that class are referred to”, because then it would be doing exactly the same thing as <memberOf>, wouldn’t it? But in fact, if it were inside an <attList> with org="choice", it would not be the same.

So maybe it makes sense to have a @class without @name. But I can’t say I think this is a good idea. At least not yet. (This, like most parts of ODD that are woefully underspecified, requires thought and discussion.)

[lb42]

OTOH why is it necessary to specify @class as well as @name? We require element names to be unique across all classes, so why not do the same for attributes?

[sydb]

?? We require element names to be unique across all modules (and thus throughout entirety of tei_all), not classes. Because they are unique across the Guidelines, elements, which declare themselves members of classes, happen to be unique within classes. But you can well imagine a customization that creates a <custom:p> element and puts it into model.pLike. Thus two elements in same class with the same (local) name.

All that said, we certainly could add the constraint “no two attributes defined in classes can have same name, even if in different classes”, but seems to me like it would be shooting ourselves in the foot. Certainly would cause trouble for @scope (in att.dimensions and att.handFeatures), @cause (in att.textCritical and att.transcriptional), @extent (in att.partials and att.dimensions), and @unit (in att.citing, att.dimensions, att.measurement, and att.milestoneUnit).

[lb42]

true dat. there is the added complications that tei attributes are not name spaced ... i hastily retract the absurd suggestion

[sydb]

Council makes GREEN to require both @class and @name.

[sydb]

Uh-oh. Can anyone (I’m thinking @lb42 or @jamescummings) explain why <attRef> is being used to point to RELAX NG pattern names in P5/Test/testplus.odd (see lines 83–90)? Seems to me to be inappropriate — a pattern name is not “the name of the attribute” being referred to, and these particular pattern names are plural, not singular. Should just be <rng:ref name="…"/> IMHO.

[sydb]

Wow. This is more problematic than I had imagined. (A ticket harder than it looks? What else is new?) The use of <attRef> with only @name (i.e., no @class) to point from within a <classSpec>[1] to a RELAX NG mutli-attribute pattern has been part of Exemplars/tei_its.odd since 2008-02.

As I said above, this strikes me as wrong. Furthermore, my initial reaction (to use RELAX NG directly), while perhaps reasonable, is not valid.

So I do not think we can strike down something that has been exemplified for almost 15 years and for which we do not seem to have any feasible replacement. Thus reverting this to NEEDS DISCUSSION, and no longer expecting to get this change into upcoming release.

[1] From /TEI/P5/Exemplars/tei_its.odd//classSpec/attList/attRef/@name in FOXpath 3.0, I think. Not sure how namespace is specified.

[sydb]

@peterstadler and I think that probably we should

1. Write a prose constraint that requires @class iff referring to an attribute in a class (i.e., an <attDef> descendant of <classSpec>), and requires not( @class ) when referring to an attribute via al RELAX NG pattern.
2. Think about whether or not we can write a formal constraint for that.
3. Arrange a meeting among the 4 assignees to hash this out.

[sydb]

ATOP group (me, @HelenaSabel, and @martindholmes) discussed this today, and affirmed the intuitions @peterstadler and I had above:

• There are two current reasonable uses of <attRef>:
  • refer to an attribute that is defined in a class in your base ODD or customization ODD — require both @class and @name
  • refer to a RELAX NG pattern that may be defined in your base ODD or customization ODD or may be something you expect to be generated by processing and thus to be in the resulting RELAX NG — @name required, @class not allowed.
• Thus @name should be changed from optional to required.
• We are not sure what formal validation can be easily performed, if any:
  • The attribute referred to from a customization ODD might be defined in the base ODD, but we may be able to get to it from schemaSpec/@source, no?
  • The pattern referred to should begin with one of the defined @prefix values, right?

[martindholmes]

Also if both @name and @class are provided, the existence of the target can be confirmed.

[sydb]

Also if both @name and @class are provided, the existence of the target can be confirmed.

At run time, yes. But (in the case that the <classSpec> is in the base ODD and we are trying to validate the customization ODD) can we confirm it via validation without actually processing the customization ODD?

Also we (the group discussing yesterday) did not fully address the “is <attRef> with only @class allowed in order to refer to an entire class” for the “inside an <attList org="choice">” case, but I think the consensus was a <classRef> should be used, instead. Have not tested, but I think that makes sense. (Also makes me wonder about the values of @expand when <classRef> refers to an attribute class, and whether or not the Stylesheets do anything with @include and @except when referring to an attr class.)

[dmj]

• refer to a RELAX NG pattern that may be defined in your base ODD or customization ODD or may be something you expect to be generated by processing and thus to be in the resulting RELAX NG — @‍name required, @‍class not allowed.

By which account is this a reasonable use? I.e. why do you need this feature?

Allowing @‍name to refer to a RELAX NG pattern is at odds with ODD as "an entirely self-contained generic specification language, independent of other existing grammars." (https://wiki.tei-c.org/index.php/ODD#.22Pure_ODD.22). I think it would be worth the effort to support attRef w/o @‍class and figure out which document modelling needs such a reference would satisfy that the Pure ODD does not satisfy.

[sydb]

@martindholmes, @HelenaSabel, and I think @dmj has a point. While inclusion of a pattern from an external RELAX NG grammar is a very reasonable thing to do, it is completely under specified. We are not convinced that it is impure, but are convinced that ATOP does not need to handle this possibility, at least not yet. Thus we are suggesting that

1. ATOP require both @name and @class on <attRef>; and
2. Council seriously consider what should be the mechanism for an ODD to grab a RELAX NG pattern for inclusion. (A new @rngPattern attribute on <attRef>, or perhaps a new generic <rngRef> element?)

[martindholmes]

@sydb, @HelenaSabel and I think that we should find out if anyone at all is using @name to point to external RNG attribute definitions; if no-one out there really is, then it's much simpler to create an alternative mechanism for use in e/g/ Exemplars/tei_its.odd, and to modify the existing stylesheets to handle it.

[martindholmes]

@sydb, @HelenaSabel and I discussed this further, and we now think there are three current possible usages of <attRef>:

1. To point to an <attDef> in a class using @name and @class. This is not problematic.
2. To point to an RNG pattern in an external module, using only @name. This, we believe, should be done with another mechanism.
3. To point to an entire attribute class from within <attList>, using only @class, perhaps in order to allow class membership in alternation with other attributes or classes. This we believe should not be a real use-case, and only arises because <classRef> is not allowed in <attList>. The current stylesheets handle it, but that's probably accidental. We think either this edge case should not be allowed, or <classRef> should be allowed in <attList> in order to handle the requirement.

To handle no. 1, we should make @name and @class mandatory. To handle no. 2, we should create another mechanism to use external RNG patterns. To handle no. 3, if indeed there's any need to, we could allow <classRef> in <attList>.

[HelenaSabel]

F2F agreement:

• @name and @class mandatory
• mechanism for pointing to RELAXNG patterns to be discussed in #2548
• <classRef> doesn’t need to be allowed in <attList>