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

[James Cummings]

On 24/10/12 16:41, Martin Holmes wrote:
> This all looks really good to me. I'm intrigued as to why <name> getting
> att.canonical twice didn't cause errors before, but perhaps ODD
> processing is robust enough to handle that now. Kudos to Sebastian, if so.

Actually I think that was my mistake... name claims membership in 
att.personal(att.naming), so gets att.canonical only once (from 
att.naming's membership in it).

Will go and implement this in principle, though I note your 
Jenkins is currently claiming something is broken somewhere.

-James

>
> Cheers,
> Martin
>
> On 12-10-24 03:42 AM, James Cummings wrote:
>> 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