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

[James Cummings]

On 30/09/11 13:52, Martin Holmes wrote:
>    >  In that world the tei module would define, as it does, the att.typed
>    >  class.  The elementSpec for list would say "I'm a member of att.typed"
>    >  by which it would gain @type and @subtype.  Then it would delete
>    >  @subtype (list doesn't have @subtype), and customise the valList of
>    >  @type to suggest values like ordered/bulleted/gloss. This way the same
>    >  customization mechanism that is used in project ODDs is used in the base
>    >  TEI ODD itself.
>
> Wouldn't this result in a situation in which<list>  was a member of
> att.typed, but didn't have @subtype? That would be seriously confusing,
> wouldn't it?

I'm a member of the University of Oxford Club (where coincidentally the 
Class War meeting took place). This means I can go sit in the bar and 
watch the cricket or go to lunch, or indeed use the exercise rooms or 
sign up for an aerobics class. I do the first two of these but not the 
second two, yet I am still a member of the club.

My analogy, for Laurent, is that TEI Class membership, especially 
attribute classes gives an element a menu of additional rights. It can 
employ some or (by default) all of these if it wants, but it doesn't 
stop it being a member of the club if it only uses some of them. I think 
this is a more intellectually honest way to have a @type attribute than 
define it again locally. We all *know* that it is the same as the 
att.typed version, it has the same content model, its description is 
almost identical, it just has some different suggested values. If we 
define it again locally we are explicitly saying that this is 
semantically different from the one in the att.type class...and I don't 
think different suggested values truly change its semantics to this degree.

-James

-- 
Dr James Cummings, InfoDev,
OUCS, University of Oxford