[tei-council] rationalizing attributes on persName/placeName/orgName/name (3519806)

[James Cummings]

In implementing http://purl.org/tei/bug/3519806 to add 
att.datable to name, as I've been tasked to do I have the 
following proposal (that I will implement before the deadline 
today if no strenuous objections are made).

The current situation:
persName: att.global, att.datable, att.editLike, att.personal, 
att.typed
placeName: att.global, att.datable, att.editLike, att.naming, 
att.typed
orgName: att.global, att.datable, att.editLike, att.personal, 
att.typed
name: att.global, att.naming, att.personal, att.typed

Note that placeName and name claim membership of att.naming which 
provides @role ("may be used to specify further information about 
the entity referenced by this name") and @nymRef ("reference to 
the canonical name") but includes att.canonical.

Note that persName and orgName claim att.personal which provides 
@full ("indicates whether the name component is given in full") 
and @sort ("specifies the sort order") but includes att.naming 
and att.canonical.

Note that name claims membership in att.naming and att.personal 
(doesn't this mean it gets att.canonical twice?) and does not get 
att.editLike which all the rest get which provides @evidence, 
@source, and @instant.

My proposal: aside from removing a prose statement saying that 
@sort only refers to personal names (which seems weird to me), I 
would like to rationalize all of these.

I would suggest that name and placeName not claim membership in 
att.naming, but instead (the probably misnamed) att.personal. I 
would also have name claim membership in att.editLike.

This would result in all
persName: att.global, att.datable, att.editLike, att.naming, 
att.typed
placeName: att.global, att.datable, att.editLike, att.naming, 
att.typed
orgName: att.global, att.datable, att.editLike, att.naming, att.typed
name: att.global, att.datable, att.editLike, att.naming, att.typed

So all of these would get the same attributes. If I've understood 
correctly then no elements would lose attributes and name would 
become significantly richer and have the same attributes of the 
others. (Which means that our claim that <*Name> is syntactic 
sugar for <name type="*"> is closer to the truth.) If implemented 
I'll make sure the descriptions are consistent.

Does anyone have any objections to this? Or does anyone see any 
major pitfalls in terms of recursive class membership that I'm 
overlooking? (If so, I'll postpone until after release.)

-James

-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford