[tei-council] signed/list

[Martin Holmes]

On 11-11-19 04:41 PM, Lou Burnard wrote:
> This is fine as a way of structuring the collection of names. But it
> still begs the question as to why we have tagged the thing as a<signed>
> in the first place. What's the added value in doing that rather than say
> wrapping them all in a<p>  or a<closer>  ? What does<signed>  MEAN?

I think <closer> typically wraps <salute> and <signed>:

<closer>
   <salute>Yours venomously,</salute>
   <signed>
       <persName>Fred Bloggs</persName>
       <persName>Joe Nonce</persName>
       <persName>A. Nonymous</persName>
   </signed>
   <date when="2011-03-14">Ides of March, 2011</date>
</closer>

So if you're processing, you know you can pull the names out of the 
<signed> block. Names might occur elsewhere in a closer (the name of the 
addressee could conceivably show up there), so the <signed> block helps 
to clarify which names belong to signers.

Cheers,
Martin

> On 20/11/11 00:35, Martin Holmes wrote:
>> How about this:
>>
>> <signed>
>>      <persName>Fred Bloggs</persName>
>>      <persName>Joe Nonce</persName>
>>      <persName>A. Nonymous</persName>
>> </signed>
>>
>> In the situation where something looks like a list, you could do this:
>>
>> <signed>
>>      <persName>Fred Bloggs</persName><lb/>
>>      <persName>Joe Nonce</persName><lb/>
>>      <persName>A. Nonymous</persName><lb/>
>> </signed>
>>
>> Does this avoid the block vs. inline issue, and provide a simple
>> solution to the multiple-signer conundrum?
>>
>> Cheers,
>> Martin
>>
>> On 11-11-19 01:34 PM, 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?
>>>
>>>     >    I really think we ought to
>>>> decide whether the second case requires three<signed>     elements or
>>>> <one>. The Guidelines are ambiguous on this point, and it is therefore
>>>> up to us to clarify them -- this is not a P6 issue, it's something where
>>>> the Guidelines are currently under specified or confusing, what we might
>>>> even call "A Bug".
>>>
>>> I agree that we should clarify our guidelines on whether, in the case of
>>> more than one person signing, you should use (A) one<signed>    or (B)
>>> multiple<signed>.
>>>
>>> It sounds like if we think you should use only one<signed>    (A), then
>>> the problem elicited by the TCP (of wanting to use<list>    within it)
>>> still stands unless we act upon
>>>
>>> http://purl.org/tei/bug/3439980
>>>
>>> whereas if we say to use<signed>    around each name (B), then we could
>>> tell the TCP to fix their encoding to conform, and, while we're thinking
>>> about this, we might tighten the content model of<signed>.  However, ...
>>>
>>>     >    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!)
>