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

[Sebastian Rahtz]

On 8 Jan 2013, at 17:52, Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info>
 wrote:

>>  <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.

correct. thats what I am imagining you doing

>> 
>> 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.

well, I'd say thats over-problematizing it. just override my suggestion
if its wrong. i honestly doubt we'll fight over it. just add more prose
as needed.

> 
>> 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. 
yup.

and the cases where the description needs a local override.

>  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.

i'd say just write prose in column A to make clear what the status
is, as much as is needed. 

> 
> 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?
> 
please god no. 150 extra tickets in SF? oh how I hate using that clumsy system.

honest, I claim its easier than you think to sort most of these. @type
will take a month of someone's life one day, however,
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431