mholmes at uvic.ca
Sat Nov 19 19:47:39 EST 2011
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>:
<date when="2011-03-14">Ides of March, 2011</date>
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.
> On 20/11/11 00:35, Martin Holmes wrote:
>> How about this:
>> <persName>Fred Bloggs</persName>
>> <persName>Joe Nonce</persName>
>> <persName>A. Nonymous</persName>
>> In the situation where something looks like a list, you could do this:
>> <persName>Fred Bloggs</persName><lb/>
>> <persName>Joe Nonce</persName><lb/>
>> <persName>A. Nonymous</persName><lb/>
>> Does this avoid the block vs. inline issue, and provide a simple
>> solution to the multiple-signer conundrum?
>> 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)
>>> 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
>>> 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!)
More information about the tei-council