[tei-council] signed/list

[Kevin Hawkins]

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