[tei-council] attribute names used in classes which are duplicated on elements

[Kevin Hawkins]

On 1/8/2013 12:13 PM, Sebastian Rahtz wrote:
> As per FR 3567935, I have compiled a catalogue at
> of all the cases where an attribute name defined in a class is also used on an element.
> This happens 49 times. Each of them needs examining to see whether they can now be
> replaced with class membership and local override of the given attribute.
>
> you can see the catalogue as an editable spreadsheet at https://docs.google.com/spreadsheet/ccc?key=0AhciBT9b4XaZdEQ1bmZ6emF0ck9GQU9sWDlFSlRkUFE
> (and with better formatting and links at http://tei.oucs.ox.ac.uk/duplatts.html).
>
> this raises many questions. A simple one:
>
>   <g>/@ref is pretty much the same as att.canonical/@ref, but if we
> add<gi>  to att.canonical, it gains @key as well.  Is that a
> Good Thing or a Bad Thing? obviously we can have the status quo,
> by adding<attDef ident="key" mode="delete"/>  to<g>

If I understand correctly, these sorts of questions are not included in 
your spreadsheet and have to be discovered by looking at each element in 
column D, and seeing whether it lacks any of the attributes that come 
along with those in the class in column B.  And then we decide whether 
we think it's good to add those attributes, keep them out using 
mode="delete", or not use the class at all.

> I think I could go ahead and do 90% of these myself by common sense, but
> thats not sensible :-}. I suggest that we use that spreadsheet
> to look at some of these cases and add a decision/recommendation/vote
> to the first column. choices may be:
>
>     easy: make all elements members of class
>     hard: make elements members of class, but with adjustments (i.e. only having some attributes from class, overriding description)
>     harder: some elements only, needs careful thought
>     impossible: the attributes are definitely not the same beast
>
> I have some suggestions already

Since you've added your suggestions there already, I guess we need to 
put "SR: " in front of each and then let people add their own votes on 
separate lines in each cell in column A.

 > Then at a second stage someone can go in and action each case.

For each "hard" we're going to have to decide which attributes will be 
included and which will have mode="delete".  And for each "harder", 
we're going to have to say which elements will get the membership class. 
  So I feel that these two labels won't actually help us reach consensus 
on these questions, and in fact, if two people choosing one of these 
labels are assuming different sets of attributes or elements to be 
affected, we might have less consensus than it appears.

In short, I feel we need a different method to tackle this problem.  Do 
we dare create a ticket for each row in the table and let people propose 
and discuss how to handle the affected elements and attributes?

K.