Menu
▾
▴
#384 free-standing attributes -> class
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
can you remove forest and forestGrp from list? I have moved them to att.typed willy-nilly.
Per Council discussion in Oxford, we decided that once this is implemented, we need to add a note to att.typed reminding people that this is meant to describe the type of element, not type of scope, function etc.
Last edit: Kevin Hawkins 2013-11-11
Good luck enforcing that... ;-)
Reassigning to PFS to follow up