[tei-council] class struggle continues

James Cummings James.Cummings at computing-services.oxford.ac.uk
Thu Apr 12 13:00:10 EDT 2007


Lou Burnard wrote:
> James Cummings wrote:
>>
>>> Seems to me that
>>> * persName ought to be a member of att.personal (definitely)
>> agreed
> 
> Unfortunately, this causes everything to break, since persName
> explicitly defines its own @type

And I assume, as below, that is because it has a useful valList?  Oh wait,
when I look it up it allows anything that is data.enumerated.  Maybe this
should change?  So I guess the problem is also partly that you want to have
descriptive prose that is different for this @type compared to the one that
is in att.typed?


>>> * @full and @sort ought to be separated from @type (maybe)
> Sometimes (about 40%) when an element has a @type, it has  inherited it
> from att.typed. Other times it defines it for itself. Usually this is
> because the locally-defined variant has a helpful valList associated
> with it. We looked at this problem, gingerly, at the class meeting in
> Oxford and then ran away from it.  att.typed also gives you @subtype
> which you may not want, but that seems to be less of an issue to me.

Yes, I remember that.  I have little problem with subtype being there
whenever type is, even if minorly inappropriate in some instances.

> I think it definitely is the right place for @nymKey. One gives you a
> pointer to the thing being named, the other gives you a pointer to the
> canonical name used for the naming.

Fair enough, thanks for the explanation, then I say rename it... but to what?

>>> * att.personal ought to be a member of att.naming (definitely)
>> agreed.
> but vide supra...

What is best to do about that? These darn type attributes.

-James



-- 
Dr James Cummings, Oxford Text Archive, University of Oxford
James dot Cummings at oucs dot ox dot ac dot uk



More information about the tei-council mailing list