[tei-council] class struggle continues
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)
> 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)
> but vide supra...
What is best to do about that? These darn type attributes.
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