[tei-council] P5 source, modifying class atts at the base level.
James.Cummings at oucs.ox.ac.uk
Sat Oct 1 05:31:22 EDT 2011
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.
Dr James Cummings, InfoDev,
OUCS, University of Oxford
More information about the tei-council