[tei-council] signed/list

[Lou Burnard]

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?



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!)