Now that local modification of class attribute is supported at the source level, we need to make a new catalogue of all attributes which have the same name as ones in classes, and which can therefore be considered as amenable to being expressed as a local modification. There are, for example, apparently 69 attributes called 'type' - most of these can very likely be turned into membership of att.typed.
I just note that @type is really the only significant case of this kind
well... there are 58 occurrences of attribute names used more than once on elements, and about 20 of those also appear in classes. http://tei.oucs.ox.ac.uk/atts.html contains the damning evidence. @scheme, @target, @value, @name, @key seem ripe for examination.
so depends on what the definitiin of significant is :-}
Assigning to rahtz to bring a proposal to Council of what attributes should change. Setting as AMBER since this will need discussion. The general idea is, of course, a good one and why we introduced this facility.
the requested catalogue is at http://tei.oucs.ox.ac.uk/duplatts.html, showing 49 cases to consider. I think they are all open to discussion. @type is the big one, but plenty of others are in double figures.
Gawd. I see both @target and @typed are in more than one attribute class. Are we thinking that an attribute class can be a local modification of another attribute class?
"Are we thinking that an attribute class can be a local modification of
another attribute class?" - thats getting tricky. Its a possibility, but first
we need to decide if they _are_ in fact the same concept. Getting to grips with
all the uses of @type is a serious undertaking :-{
something like @hand or @wit is easier to sort out
As I suggested above, @type is probably the only really significant problem area. Most of the others are easily resolved. When resolving them though, I am worrying that we will often be adding irrelevant attributes just for the sake of tidiness. In at least some cases where @x is defined locally rather than inherited from att.whatever, it's because att.whatever also supplies attributes @y and @z which are not relevant. Do we really want to make loads of subclasses?
You can have a local modification to remove unwanted attributes, but when I proposed and did this in 2012, I got burnt at the stake for heresy by some people. I am not we ever resolved it after an argument in Ann Arbor.
I have made a first stab at an inventory of free-standing instances of @type in a Google Doc. Confirmation of or disagreement with my recommendations is welcome.
https://docs.google.com/spreadsheet/ccc?key=0AtV1qdTijAwLdDBPay1vLVh6Q2dOS19JdkUwUkhibmc&usp=sharing (anyone with the link should be able to comment; let me know if you wish to be able to edit)
Last edit: Rebecca Welzenbach 2013-11-11