Several interesting points here...

Firstly,  surely this is the wrong way round? If we're doing functional 
markup, then the word "Witnesses" is a label, associated with an item, 
which contains a list, containing the two names.


<list type="gloss" rend="braced-right">
<item><list><item><name>Duncan Campbell</name>,</item>
<item><name>Iohn Thom</name>,</item></list></item>
<label>Witnesses.</label>
</list>

BTW, <list rend="braced"> is a frequently discussed item on TEI-L; for 
some lively examples see 
http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind9710&L=TEI-L&P=R1315; http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind0802&L=TEI-L&P=R8776; 
 
http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind0701&L=TEI-L&P=R8957 
and the magisterial
http://www.lib.umich.edu/tcp/docs/dox/instruct2.html#braces)

However:

P5 requires that in the model for <list type="gloss">, the <label> 
should precede the <item>. There's no good reason for this (except that 
the content model is already quite a headache to parse) so you could 
plausibly raise that as a feature request. Or you could just accept that 
the sequence of the components in your encoding isn't identical to that 
in which one might expect the eye to read the page.

P5 also requires that all model.divBot class elements (<signed> <closer> 
etc.)  should be phrase level elements, as should their contents. The 
former restriction is necessary to avoid ambiguous content models; the 
latter may be debatable.

Fortunately, there's a much simpler way of encoding this! Just treat the 
whole thing as a list :

<list type="closer">
<item><signed>ARGYLE.</signed></item>
<item>
   <list type="gloss" rend="braced-right">
   <label>Witnesses.</label>
   <item>
     <list>
       <item><name>Duncan Campbell</name>,</item>
       <item><name>Iohn Thom</name>,</item>
     </list>
   </item>
   </list>
</item>
</list>

which is valid against TEI Lite. And, I contend, does at least as good a 
job of representing the structure and meaning of the page as any of the 
other options!


On 28/08/11 05:02, Martin Mueller wrote:
> I have been playing around with wrestling the EEBO dtd into a pure
> version of P5. I'd be grateful for some help with the following
> fragment, which is certainly /multum//in parvo. /Just in case the email
> messes with the image below, you can read this post also at
> http://ariadne.northwestern.edu/mmueller/label-list.htm.
>
> Actually, the original version of this post was rejected by the listserv
> because it is configured to reject attachments of the type image/png.
> This seems to me to be a mistake. When I look at an encoding problem in
> a TEI text (typically a TCP text) and am puzzled, I typically find that
> seeing the bit of the page image from which a particular encoding was
> derived is a good way of "seeing" the problem. So I think the listserv
> should encourage discussions where snippets of page images illuminate
> the problem and point to a solution.
>
> //
>
> In Wing C1066, a 17th century legal case, there is a letter of attorney
> by the Earl of Argyle, the end of which reads as follows:
>
> [here would have been the image that the listserv rejected and that you
> can see at the URL above]
>
> A human reader has no trouble seeing that "ARGYLE" represents a
> signature that is witnessed by men who sign their names.
>
> The TCP SGML representation of this goes as follows:
>
> <CLOSER>
>
> <SIGNED>ARGYLE.</SIGNED>
>
> <SIGNED>
>
> <LIST>
>
> <LABEL>
>
> <LIST>
>
> <ITEM>,</ITEM>
>
> <ITEM></ITEM>
>
> </LIST>
>
> </LABEL>
>
> <ITEM>Witnesses.</ITEM>
>
> </LIST>
>
> </SIGNED>
>
> </CLOSER>
>
> The following goes on here:
>
> 1.All the signatures are wrapped in a closer.
>
> 2.The Earl signs by himself.
>
> 3.The signatures of the witnesses are a list .
>
> 4.Because there is a many-to-one relation in the two names and the one
> designation 'witnesses' the label-item relationship is complicated by
> representing the two names as a list child of label.
>
> It all makes sense but makes you marvel at the ways in which human
> readers make sense of the sparse symbols on the printed page.
>
> It turns out to be surprisingly difficult to model these relationships
> in P5. If you don't like the EEBO label/list option (and I'm not sure I
> do) you could use a table structure with a @rows attribute, as in
>
> <table>
>
> <row>
>
> <cell>Duncan Campbell,</cell><cell rows="2">Witnesses</cell>
>
> </row>
>
> <row>
>
> <cell>John Thom,</cell>
>
> </row>
>
> </table>
>
> But you can't put that either inside or after <closer>. The closest I
> can come in P5 is something like
>
> <ab type="signed">Argyle</ab>
>
> <ab type="signed">
>
> <table>
>
> <row><cell>Duncan Campbell,</cell><cell cols="2">Witnesses</cell></row>
>
> <row><cell>John Thom,</cell></row>
>
> </table>
>
> </ab>
>
> But I wouldn't say anything in favour of this except for the fact that
> it is valid. It may be that more flexibility in structure and placement
> of signatures is required to allow for the representation of what are
> quite common phenomena in legal or official documents.
>
> The "list child of label" phenomenon occurs in other contexts in EEBO
> texts. It is not very common (I count about 250 occurrences in 40 out of
> 28,000 files, and I may be way off), but it responds to a real need. You
> see it quite a bit in cast lists where several names are mapped to one
> role description via braces, as in the example above. Is there a
> preferred way of dealing with this in P5 — preferable in a Pythonic or
> Birnbaumian spirit of DOING THE SAME THING IN THE SAME WAY, as long as
> it really is THESAME THING (more or less)?
>