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

[Martin Holmes]

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

Cheers,
Martin

On 11-09-30 03:03 AM, James Cummings wrote:
> On 30/09/11 10:13, Sebastian Rahtz wrote:
>> James and I met this last night again.
>>
>> look at<abbr>. instead of being a member of att.typed, it defines its own
>> @type attribute, because it wants to supply a<valList>.  What one would like
>> to do is say<attDef mode="change" ident="type">   inside the original source
>> of P5. We can't do that now, because the processing does not support it at all,
>> but in general, do people believe that it _should_ work?
>
> I believe Sebastian knows my opinion about this but I will re-iterate it
> here. (I think I've mentioned it before ages ago when discussing how ODD
> works.)
>
> When I look through the TEI's list of attributes and find multiple
> locally defined attributes of the same name I wonder to myself "Why
> aren't these in a class". In almost every case I could find it is
> because the<desc>,<remarks>, or<valList>  is changed. e.g. @type on
> <list>  suggests things like bulleted, gloss, whereas att.typed of course
> does no such thing. Having to define attributes locally to change a
> couple words of their description (to make them more specific to that
> particular element) is a failure of the class system. (Well, more
> accurately I think the class system allows us not to do this but our
> current processing doesn't.)
>
> In my project ODD I can override whatever the attribute class provides
> me for any specific element.  I do not think this should be different
> for the base TEI ODD itself.
>
> 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.
>
> -James
>