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

[Martin Holmes]

My Jinks build of P5-Documentation failed because of an SVN connection 
failure -- looks like Sourceforge isn't quite back to normal yet. But 
when the current build of P5-Test is done, it'll kick off another 
Documentation build, and hopefully that'll complete OK.

Cheers,
Martin

On 12-10-24 09:22 AM, James Cummings wrote:
> 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
>>>
>>
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)