[tei-council] signed/list

[Lou Burnard]

On 19/11/11 21:34, Kevin Hawkins wrote:
>
>
> On 11/19/11 4:12 PM, Lou Burnard wrote:
>> On 19/11/11 20:30, Kevin Hawkins wrote:
>>>
>>
>>>
>>> Still, even with a narrow definition of<signed>    that said to use this
>>> for only names of people signing, I don't see why we wouldn't allow
>>> people to include an embedded<list>    with an<item>    around each name.  I
>>> realize the content model wouldn't be as elegant as use of
>>> model.nameLike, as Lou proposed, but I don't see how we could justify
>>> not allowing<list>    here.
>>
>>
>> There is a difference between "signed by Kevin Barry Cholmondeleye
>> Smythe Benkins Hawkins" (one person) and "signed by  Kevin Barry
>> Cholmondeleye Smythe Benkins Hawkins" (three people), right?
>   >
>> I can see a case for allowing<list>   inside<signed>   in  either case
>> (though it makes more sense in the first).
>
> Lou, I don't understand what you're saying.  The string of characters in
> each is identical, and I'm not sure how I would read *either* as
> denoting one or three persons.  Can you give less fantastical examples?


Apologies for being fantastical (actually, dammit, I retract that: I 
*like* being fantastical)

Martin posted a real life example, I think, where you have a sequence of 
words which you could interpret either as indicating that a number of 
people had signed, or as indicating that one person with several names 
has signed. Yes it's a matter of interpretation, but so is the choice of 
<signed> : I just want to get as much value as possible out of that choice.

>
>   >  My recommendation is not to change the  content model
>> but to clarify the way the existing content model should be used.
>
> Oh, so you retract your wish to "see the content of<signed>  narrowed
> down to include only model.nameLike vel sim."?  That is, we would
> continue to allow people to use<signed>  for more than one name as
> allowed by its current, sloppy content model?  (Just checking that I'm
> following what's going on!)


Sorry if it's not clear -- I am agreeing with Sebastian's last comment 
-- we should leave the content model as it is out of respect for legacy 
data, but we should tighten up the prose and examples to make clear what 
is our recommended practice -- namely that multiple people signing 
whether in a list or as a stream of text should be encoded using 
multiple <signed>s. I would rather do that than make the situation worse 
by implementing the proposal in http://purl.org/tei/bug/3439980 for the 
reason I give on that ticket -- namely that if <signed> contains 
macro.paraContent it is indistinguishable from <closer>.