Print

Print


On Sat, 27 Aug 2011, 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.
> 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:
> A human reader has no trouble seeing that "ARGYLE" represents a signature
> that is witnessed by men who sign their names.

Perhaps, since I am responsible for some of the reckless changes
mentioned here, I might distinguish between them, since they
involve several different issues.

(1) One of our TCP customizations is to allow <list> within <signed>.
This responds, I believe, to a real need to list signatories,
but it is a need aggravated somewhat by the inclusive way that
we have chosen to interpret <signed> itself, as including
phrases descriptive of the signatories. Typical example
(invented, but there are many many similar real ones):

   <CLOSER>
   <DATELINE>
   From the parish of Brookhurst, <DATE>26 August 1657</DATE>
   </DATELINE>
   <SIGNED>Your devoted brethren,
      <LIST>
      <ITEM>John Smith.</ITEM>
      <ITEM>Richard Jones.</ITEM>
      <ITEM>Thomas Goodfellow.</ITEM>
      </LIST>
   Preachers of the Gospel in Buckinghamshire.</SIGNED>
   </CLOSER>

   (place optional <NAME> tags around the three signatories if \
   you like, but they still constitute a LIST within SIGNED,
   and they all belong in the same <SIGNED> element as the
   phrases that describe them ('devoted brethren,' 'preachers
   of the gospel').)

(2) Another, bolder, customization was to allow LIST within LABEL. On
this we were on far shakier ground: the innovation arose partly
in response to real use cases (mostly involving real glossary-type
lists), and partly in an abortive move on our part to broaden the
application of LABEL-ITEM lists (HTML <dl>) precisely in the
direction Martin suggests, towards equivalence, more or less,
with two-column tables, regardless of whether they involve lemmas
and definitions or not. (Since then we have grown more timid and
used LABEL-ITEM lists more restrictively, and do try to confine them
to things that can if only broadly speaking be described as pairs
of terms and glosses). My only point here is that the (rare) need
for LIST within LABEL occurs whether or not you confine LABEL-ITEM
lists to glossaries; and certainly whether or not you allow the list
itself within SIGNED.

   <LIST TYPE="glossary">
   <LABEL>Bradbrook.</LABEL>
     <ITEM>Dweller by the broad brook.</ITEM>
   <LABEL>
     <LIST>
       <ITEM>Bradbourn.</ITEM>
       <ITEM>Bradburn.</ITEM>
       <ITEM>Broadbin.</ITEM>
     </LIST>
   </LABEL>
     <ITEM>Dweller by the broad stream.</ITEM>
   </LIST>


(3) Legal and official documents place many strains on the
simple model of CLOSER, SIGNED, SALUTE etc., of which Martin's
example is only a tiny sample, mostly because legal documents
are often composed by a kind of layering of responsibility, each
layer leaving a documentary trace behind: testators sign,
witnesses sign, notaries sign, secretaries sign, endorsers
sign, enrollers sign, extractors from the rolls sign, etc.,
often in labeled groups.

pfs


>
> The TCP SGML representation of this goes as follows:
>
>
> <CLOSER>
>     <SIGNED>ARGYLE.</SIGNED>
>     <SIGNED>
>         <LIST>
>              <LABEL>
>                  <LIST>
>                       <ITEM>Duncan Campbell,</ITEM>
>                       <ITEM>Iohn Thom,</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)?
>
>
>

--------------------------------------------------------------------
Paul Schaffner | [log in to unmask] | http://www.umich.edu/~pfs/
316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190
--------------------------------------------------------------------