[tei-council] P5 source, modifying class atts at the base level.

[James Cummings]

On 30/09/11 10:42, Lou Burnard wrote:
> But fwiw, I think supplying valLists in the P5 source is, in general, a
> bad idea. That is something which projects should be encouraged to do
> for themselves in their own ODDs. The Guidelines should (in general)
> specify a datatype, and may (sometimes) provide a list of suggested
> values in order to indicate the intended semantics of the attribute, but
> the TEI per se is not in the business of enumerating all possible
> attribute value lists.

I agree that providing _closed_ valLists in the TEI Guidelines is 
generally a bad idea (unless there really is only a fixed list of values 
and then datatypes are better). I think providing suggested values is a 
good idea where applicable, to encourage standardization on these 
values. However I think it is a failure of our processing to have to 
define an element locally, not as part of a class, to give those 
suggested values on one particular element. (e.g. @type on list). 
However it isn't just @type this happens with, it happens with all sorts 
of attributes.


> There is a case for being able to specify a different set of suggested
> values on some member of a class than that it would otherwise inherit.
> This typically arises where the inherited attribute is too vague in its
> semantics (@type being a notable offender here, which is one reason I
> dislike its use as a panacea) and at present the appropriate syntactic
> mechanism for resolving it is to redefine the attribute locally.

But we don't 'redefine' the attribute locally we 're-define' it, if you 
take my implied emphasis. That is we create an entirely new attribute 
with the same name as the one in the class rather than giving the 
existing attribute in the class a new definition.  The @type from 
att.typed and the list/@type are completed different entities with 
nothing semantically or syntactically linking them.  I feel it would be 
_much_ more powerful and more consistent with the aims of the TEI class 
system if we were able to say that there is this general @type attribute 
of which the instantiation on the list element has a new list of 
suggested values.

> We could certainly consider adding some other syntactic mechanism to
> achieve the same goal, as you suggest, by using mode="change". But I
> think that somewhat confuses the issue. Either this attribute is a
> member of the class or it isn't. If it is, then changing it anywhere
> affects all instances equally: that's what being a member of a class
> means. Or it isn't, in which case we cannot be "changing" it here, but
> rather adding a different one which happens to have the same name
> (that's the current way of doing it).

I see what you are saying, but disagree that changing an element's use 
of a class changes it anywhere. This certainly isn't how the current 
processing works.  The climate element is a member of att.typed, but if 
in my project ODD I want to modify this to delete @subtype and provide a 
new list of suggested values I do this in the elementSpec for climate 
with a mode="change". If I do so it does not change it for eLeaf (which 
is also a member of att.typed). You might view this as adding a new one 
with the same name, but to me it seems that this preserves the semantic 
heritage of where this attribute came from rather than re-creating it 
from scratch.

> If we're really dissatisfied with the status quo, I'd say a different
> value for @mode ("override"?) would be much clearer. But I'm still
> unconvinced.

I'm not sure why changing it in a project ODD is 'change' but changing 
it in the source itself is 'override'? Other than this being the base UR 
text of the TEI, how is it a different action?

I'm happy to be corrected in my misunderstandings. I just want to get 
rid of the duplication of locally-defined attributes as much as is 
humanly possible. I was there for the Class War and am convinced that 
the TEI class system is the one true way. :-)

-James

-- 
Dr James Cummings, InfoDev
Oxford University Computing Services
University of Oxford