[tei-council] FR 470: attribute/class problems

[Martin Holmes]

Hi all,

On the Council telco, Syd raised the issue of needing to abstract 
attributes from local definitions into a class, in order to provide them 
with the same valList in one location. Working on 
https://sourceforge.net/p/tei/feature-requests/470/, I've come across 
something slightly related.

This FR points out that att.measurement provides for <measure> and 
<measureGrp> two attributes (@unit and @quantity) which are also 
provided by att.dimensions. Council therefore decided to do this:

1. Move @commodity (the only other att in att.measurement) from 
att.measurement into a new class, att.commodity.

2. Add measure and measureGrp to att.commodity.

3. Add measure and measureGrp to att.dimensions.

4. Override the definitions of @unit and @quantity on <measure> and 
<measureGrp> to supply suggested values that were originally part of 
their definitions in att.measurement.

This seemed to be a classic case of using the new capability of 
overriding class attributes at the element level to improve clarity and 
elegance.

If you think about it, though, by moving these attributes out of a class 
where they have a single valList and overriding them at the element 
level, we now need to define the same valList twice (once in <measure> 
and once in <measureGrp>) to get the same result. Now we have duplicated 
definitions and the consequent potential for inadvertent divergence.

In other words, we have more rather than less complexity. I think there 
are only two solutions to this:

1. We keep the current situation.

2. We consider the possibility of a mechanism that would enable us to 
add att.measurement to att.dimensions, so that att.measurement inherits 
@unit and @quantity from att.dimensions, but overrides the definitions 
of the attributes at that class level (in the process adding 
@commodity); <measure> and <measureGrp> remain members of att.dimensions 
and therefore inherit the modified attributes from there.

Thoughts? Could #2 work? Would it even perhaps work out of the box? (I'd 
be amazed if it didn't break DTD generation.)

My preference would be for #1 right now, with #2 as a long-term goal 
after we drop support for DTDs, as part of making the class system more 
of a true inheritance structure. I think it would be really useful to 
have the ability to define attributes with successive levels of 
specificity, with elements having the ability to select a particular 
version of an attribute from a particular class at any point in the 
tree. For that reason we could set the ticket to red to keep it around 
as a test case for such future developments in ODD.

Cheers,
Martin