correspondence encoding problems: letter headings

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

correspondence encoding problems: letter headings

ron.vandenbranden
Administrator
Hi,

We're (finally) moving to TEI P5 for correspondence encoding, and would
like to stick to "vanilla" TEI as much as possible. While the TEI
correspDesc module does a great job in defining and explaining elements
for encoding metadata for letters, we often find ourselves struggling
with ways to transcribe actual text elements.

One is the letter heading. At first glance, something like
(ab|div)[@type='letterhead'] would seem a plausible candidate encoding
(I've found a concrete example on slide 40 of the presentation at
https://drive.google.com/file/d/0B_1qUxvG29kvekJDZzQzZ1JZT0E/view). Yet,
it seems to be more complicated than this. Typically (but not
necessarily), letter headings occur at the start of a letter, before the
opening salutation, etc. However, <div> nor <ab> are allowed before
<opener> (or any other model.divTop elements). Following encoding hence
is invalid:

   <!-- invalid -->
   <body>
     <div type="letter">
       <ab type="letterhead">...</ab>
       <opener>...</opener>
       <p>...</p>
     </div>
   </body>

Looking for possible (TEI) solutions, these seem to be the options:
     [1] abstraction: encode <ab type="letterhead"> after <opener>
         [+] easy; <ab> is flexible enough to occur in many places
(except before and inside <opener>)
         [-] less faithful to the source
     [2] encode <seg type="letterhead"> inside <opener> (since <div> nor
<ab> are allowed inside <opener>)
         [-] not sure if this could be considered as part of the opener,
really; <seg> is an inline element
     [3] encode letter heading as <opener rend="letterhead">, sibling to
the regular <opener>
         [+] quite elegant (and <closer rend="letterhead"> would be a
viable analogy for letter headings occurring at the end of a letter)
         [-] tag abuse?  what about letter headings occurring at
different locations?
     [4] encode letter heading before <opener> as <head
type="letterhead">, *if* it can be considered a title to the letter, really
         [+] could be useful without too much "semantic stretch" for the
<head> element
         [-] <head> can only occur as the first element, so unusable for
encoding letter headings at different locations
     [5] encode letter heading before <opener> as <figure
type="letterhead">, *if* it can be considered a graphical element, really
         [+] <figure> is flexible enough to occur in many places (even
inside <opener>, if needed), and leaves different encoding options:
                 -only signal its presence: empty <figure
type="letterhead"/>, possibly with a description in <figDesc>
                 -transcribe its textual contents inside <figure>
                 -include a digital image with <graphic/>
         [-] tag abuse?

Following example illustrates these options in different <div
type="letter"> sections:

     <body>
       <!-- option [1]: ab[@type="letterhead"] after opener -->
       <div type="letter">
         <opener>...</opener>
         <ab type="letterhead">...</ab>
         <p>...</p>
       </div>
       <!-- option [2]: seg[@type="letterhead"] inside opener -->
       <div type="letter">
         <opener>
           <seg type="letterhead">...</seg>
         </opener>
         <p>...</p>
       </div>
       <!-- option [3]: opener[@rend="letterhead"] before actual opener -->
       <div type="letter">
         <opener rend="letterhead">...</opener>
         <opener>...</opener>
         <p>...</p>
       </div>
       <!-- option [4]: head[@type="letterhead"] before actual opener -->
       <div type="letter">
         <head type="letterhead">...</head>
         <opener>...</opener>
         <p>...</p>
       </div>
       <!-- option [5]: figure[@type="letterhead"] before actual opener -->
       <div type="letter">
         <figure type="letterhead">
           <figDesc><!-- a description --></figDesc>
           <graphic url=""><!-- a link to a graphical representation --></graphic>
           <!-- transcription of text contents -->
         </figure>
         <opener rend="letterhead"><!-- option [3] --></opener>
         <opener>
           <seg type="letterhead"><!-- option [2] --></seg>
         </opener>
         <ab type="letterhead"><!-- option [1] --></ab>
         <p>...</p>
       </div>
     </body>

Am I overlooking any other options? How is this being dealt with in
other projects?

Personally, I'm getting very much in favour of option [5] (<figure
type="letterhead">), since it
     -is flexible (encoders can choose how "deep" they want to encode
the letter heading)
     -allows for uniform encoding of letter headings (<figure> can occur
anywhere)
     -is quite faithful (letter headings do have graphical qualities,
after all)
Or are there reasons not to take this option?

Many thanks for your thoughts,

Ron
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: correspondence encoding problems: letter headings

Paul Schaffner
Hi Ron,
  We have not dealt with (printed) letterhead, so I can't speak from
experience, but I would challenge your statement under option (4)
that 'head can only appear as the first element': head is just one
among many div-top elements, and it can appear anywhere amongst
them, e.g. you can have opener-argument-head-opener in that order,
if you want (and its div-bottom counterpart, trailer, can likewise
appear
anywhere amongst the div-bottom elements.) I'm not sure that head
is always the best solution, but it seems to me the most comfortable
fall-back, default, solution. And if it contains graphic elements, there
is no reason not to wrap <figure> within <head>. The only problem
with head is that its content may not include all the elements some
letterheads may demand.

For what it is worth, we use head for things like portraits that appear
at the beginning of chapters, e.g. a portrait of Henry VIII that appears
in a book on English kings, at the head of the chapter on Henry VIII.

<head type="illustration">
  <figure><figdesc>portrait of Henry VIII</figdesc></figure>
</head>
<head type="main">
  The LIFE OF HENRY VIII
</head>
<head type="sub">
  Matrimony and Controversy
</head>

I.e., we'd reverse your predilections between head and figure.

pfs


On Wed, Feb 22, 2017, at 09:54, Ron Van den Branden wrote:

> Hi,
>
> We're (finally) moving to TEI P5 for correspondence encoding, and would
> like to stick to "vanilla" TEI as much as possible. While the TEI
> correspDesc module does a great job in defining and explaining elements
> for encoding metadata for letters, we often find ourselves struggling
> with ways to transcribe actual text elements.
>
> One is the letter heading. At first glance, something like
> (ab|div)[@type='letterhead'] would seem a plausible candidate encoding
> (I've found a concrete example on slide 40 of the presentation at
> https://drive.google.com/file/d/0B_1qUxvG29kvekJDZzQzZ1JZT0E/view). Yet,
> it seems to be more complicated than this. Typically (but not
> necessarily), letter headings occur at the start of a letter, before the
> opening salutation, etc. However, <div> nor <ab> are allowed before
> <opener> (or any other model.divTop elements). Following encoding hence
> is invalid:
>
>    <!-- invalid -->
>    <body>
>      <div type="letter">
>        <ab type="letterhead">...</ab>
>        <opener>...</opener>
>        <p>...</p>
>      </div>
>    </body>
>
> Looking for possible (TEI) solutions, these seem to be the options:
>      [1] abstraction: encode <ab type="letterhead"> after <opener>
>          [+] easy; <ab> is flexible enough to occur in many places
> (except before and inside <opener>)
>          [-] less faithful to the source
>      [2] encode <seg type="letterhead"> inside <opener> (since <div> nor
> <ab> are allowed inside <opener>)
>          [-] not sure if this could be considered as part of the opener,
> really; <seg> is an inline element
>      [3] encode letter heading as <opener rend="letterhead">, sibling to
> the regular <opener>
>          [+] quite elegant (and <closer rend="letterhead"> would be a
> viable analogy for letter headings occurring at the end of a letter)
>          [-] tag abuse?  what about letter headings occurring at
> different locations?
>      [4] encode letter heading before <opener> as <head
> type="letterhead">, *if* it can be considered a title to the letter,
> really
>          [+] could be useful without too much "semantic stretch" for the
> <head> element
>          [-] <head> can only occur as the first element, so unusable for
> encoding letter headings at different locations
>      [5] encode letter heading before <opener> as <figure
> type="letterhead">, *if* it can be considered a graphical element, really
>          [+] <figure> is flexible enough to occur in many places (even
> inside <opener>, if needed), and leaves different encoding options:
>                  -only signal its presence: empty <figure
> type="letterhead"/>, possibly with a description in <figDesc>
>                  -transcribe its textual contents inside <figure>
>                  -include a digital image with <graphic/>
>          [-] tag abuse?
>
> Following example illustrates these options in different <div
> type="letter"> sections:
>
>      <body>
>        <!-- option [1]: ab[@type="letterhead"] after opener -->
>        <div type="letter">
>          <opener>...</opener>
>          <ab type="letterhead">...</ab>
>          <p>...</p>
>        </div>
>        <!-- option [2]: seg[@type="letterhead"] inside opener -->
>        <div type="letter">
>          <opener>
>            <seg type="letterhead">...</seg>
>          </opener>
>          <p>...</p>
>        </div>
>        <!-- option [3]: opener[@rend="letterhead"] before actual opener
>        -->
>        <div type="letter">
>          <opener rend="letterhead">...</opener>
>          <opener>...</opener>
>          <p>...</p>
>        </div>
>        <!-- option [4]: head[@type="letterhead"] before actual opener -->
>        <div type="letter">
>          <head type="letterhead">...</head>
>          <opener>...</opener>
>          <p>...</p>
>        </div>
>        <!-- option [5]: figure[@type="letterhead"] before actual opener
>        -->
>        <div type="letter">
>          <figure type="letterhead">
>            <figDesc><!-- a description --></figDesc>
>            <graphic url=""><!-- a link to a graphical representation
>            --></graphic>
>            <!-- transcription of text contents -->
>          </figure>
>          <opener rend="letterhead"><!-- option [3] --></opener>
>          <opener>
>            <seg type="letterhead"><!-- option [2] --></seg>
>          </opener>
>          <ab type="letterhead"><!-- option [1] --></ab>
>          <p>...</p>
>        </div>
>      </body>
>
> Am I overlooking any other options? How is this being dealt with in
> other projects?
>
> Personally, I'm getting very much in favour of option [5] (<figure
> type="letterhead">), since it
>      -is flexible (encoders can choose how "deep" they want to encode
> the letter heading)
>      -allows for uniform encoding of letter headings (<figure> can occur
> anywhere)
>      -is quite faithful (letter headings do have graphical qualities,
> after all)
> Or are there reasons not to take this option?
>
> Many thanks for your thoughts,
>
> Ron
--
Paul Schaffner  Digital Library Production Service
[hidden email] | http://www.umich.edu/~pfs/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: correspondence encoding problems: letter headings

Peter Stadler
In reply to this post by ron.vandenbranden
Hi Ron,

it would mean a little restructuring but what about
<div type="letter">
    <div type="letterHead"/>
    <div type="letterBody"/>
</div>

Best
Peter

> Am 22.02.2017 um 15:54 schrieb Ron Van den Branden <[hidden email]>:
>
> Hi,
>
> We're (finally) moving to TEI P5 for correspondence encoding, and would like to stick to "vanilla" TEI as much as possible. While the TEI correspDesc module does a great job in defining and explaining elements for encoding metadata for letters, we often find ourselves struggling with ways to transcribe actual text elements.
>
> One is the letter heading. At first glance, something like (ab|div)[@type='letterhead'] would seem a plausible candidate encoding (I've found a concrete example on slide 40 of the presentation at https://drive.google.com/file/d/0B_1qUxvG29kvekJDZzQzZ1JZT0E/view). Yet, it seems to be more complicated than this. Typically (but not necessarily), letter headings occur at the start of a letter, before the opening salutation, etc. However, <div> nor <ab> are allowed before <opener> (or any other model.divTop elements). Following encoding hence is invalid:
>
>  <!-- invalid -->
>  <body>
>    <div type="letter">
>      <ab type="letterhead">...</ab>
>      <opener>...</opener>
>      <p>...</p>
>    </div>
>  </body>
>
> Looking for possible (TEI) solutions, these seem to be the options:
>    [1] abstraction: encode <ab type="letterhead"> after <opener>
>        [+] easy; <ab> is flexible enough to occur in many places (except before and inside <opener>)
>        [-] less faithful to the source
>    [2] encode <seg type="letterhead"> inside <opener> (since <div> nor <ab> are allowed inside <opener>)
>        [-] not sure if this could be considered as part of the opener, really; <seg> is an inline element
>    [3] encode letter heading as <opener rend="letterhead">, sibling to the regular <opener>
>        [+] quite elegant (and <closer rend="letterhead"> would be a viable analogy for letter headings occurring at the end of a letter)
>        [-] tag abuse?  what about letter headings occurring at different locations?
>    [4] encode letter heading before <opener> as <head type="letterhead">, *if* it can be considered a title to the letter, really
>        [+] could be useful without too much "semantic stretch" for the <head> element
>        [-] <head> can only occur as the first element, so unusable for encoding letter headings at different locations
>    [5] encode letter heading before <opener> as <figure type="letterhead">, *if* it can be considered a graphical element, really
>        [+] <figure> is flexible enough to occur in many places (even inside <opener>, if needed), and leaves different encoding options:
>                -only signal its presence: empty <figure type="letterhead"/>, possibly with a description in <figDesc>
>                -transcribe its textual contents inside <figure>
>                -include a digital image with <graphic/>
>        [-] tag abuse?
>
> Following example illustrates these options in different <div type="letter"> sections:
>
>    <body>
>      <!-- option [1]: ab[@type="letterhead"] after opener -->
>      <div type="letter">
>        <opener>...</opener>
>        <ab type="letterhead">...</ab>
>        <p>...</p>
>      </div>
>      <!-- option [2]: seg[@type="letterhead"] inside opener -->
>      <div type="letter">
>        <opener>
>          <seg type="letterhead">...</seg>
>        </opener>
>        <p>...</p>
>      </div>
>      <!-- option [3]: opener[@rend="letterhead"] before actual opener -->
>      <div type="letter">
>        <opener rend="letterhead">...</opener>
>        <opener>...</opener>
>        <p>...</p>
>      </div>
>      <!-- option [4]: head[@type="letterhead"] before actual opener -->
>      <div type="letter">
>        <head type="letterhead">...</head>
>        <opener>...</opener>
>        <p>...</p>
>      </div>
>      <!-- option [5]: figure[@type="letterhead"] before actual opener -->
>      <div type="letter">
>        <figure type="letterhead">
>          <figDesc><!-- a description --></figDesc>
>          <graphic url=""><!-- a link to a graphical representation --></graphic>
>          <!-- transcription of text contents -->
>        </figure>
>        <opener rend="letterhead"><!-- option [3] --></opener>
>        <opener>
>          <seg type="letterhead"><!-- option [2] --></seg>
>        </opener>
>        <ab type="letterhead"><!-- option [1] --></ab>
>        <p>...</p>
>      </div>
>    </body>
>
> Am I overlooking any other options? How is this being dealt with in other projects?
>
> Personally, I'm getting very much in favour of option [5] (<figure type="letterhead">), since it
>    -is flexible (encoders can choose how "deep" they want to encode the letter heading)
>    -allows for uniform encoding of letter headings (<figure> can occur anywhere)
>    -is quite faithful (letter headings do have graphical qualities, after all)
> Or are there reasons not to take this option?
>
> Many thanks for your thoughts,
>
> Ron
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: correspondence encoding problems: letter headings

ron.vandenbranden
Administrator
Hi Paul and Peter,

Many thanks for your replies, I'll comment on both here.

Thanks, Paul, for correcting my limited assumptions about <head>, and
pointing me to the corresponding <trailer> element. I agree they make an
appealing pair for encoding letterheads occurring at the start and end
of a letter.

Peter, your proposal is elegant and tempting as well.

Yet, what about letters written on multiple pages, each containing a
letterhead (and not necessarily the same)? I think this would make both
approaches less straightforward. For the sake of the argument, I'll
assume the structure of a 2-page letter, both containing a leading and
trailing letterhead.

-<head> / <trailer>: since they can't be intermingled with <p>'s, each
page would have to be transcribed in a separate <div>, instead of being
marked with <pb/>:

   <div type="letter">
     <div type="page">
       <head type="letterHead">...</head>
       <opener>...</opener>
       <p>...</p>
       <trailer type="letterHead">...</trailer>
     </div>
     <div type="page">
       <head type="letterHead">...</head>
       <p>...</p>
       <closer>...</closer>
       <trailer type="letterHead">...</trailer>
     </div>
   </div>

This wrapping of pages in <div>s seems to go against the logical content
of the document, especially when a paragraph is split over a page
boundary (which has been the motivation for <pb/>).

-<div type="letterHead">: this would require the <div type="letterBody">
to be split for each new page:

   <div type="letter">
     <div type="letterHead">...</div>
     <div type="letterBody">
       <opener>...</opener>
       <p>...</p>
     </div>
     <div type="letterHead">...</div>
     <pb/>
     <div type="letterHead">...</div>
     <div type="letterBody">
       <p>...</p>
       <closer>...</closer>
     </div>
     <div type="letterHead">...</div>
   </div>

I can imagine that both could be linked with @next / @prev, but still it
seems highly artificial.

OTOH, and that's what I like about the flexibility of <figure>, this is
perfectly valid:

   <div type="letter">
     <figure type="letterHead">...</figure>
     <opener>...</opener>
     <p>...</p>
     <figure type="letterHead">...</figure>
     <pb/>
     <figure type="letterHead">...</figure>
     <p>...</p>
     <closer>...</closer>
     <figure type="letterHead">...</figure>
   </div>

I had to argue with myself about the <figure>-ness of letterheads, but
the fact that they're typically the result of a lay-out process in the
design of the letter paper seems to be an argument in favour.

Best,

Ron

On 22/02/2017 16:52, Peter Stadler wrote:

> Hi Ron,
>
> it would mean a little restructuring but what about
> <div type="letter">
>      <div type="letterHead"/>
>      <div type="letterBody"/>
> </div>
>
> Best
> Peter
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: correspondence encoding problems: letter headings

Elisa Beshero-Bondar-2
Dear Ron (and Paul and Peter),
The letters I work on aren't on letterhead, but in my university life I am often having to prepare a formal letter to be sent on the stuff, which usually involves a little awareness of spacing on the page and some sense that the printing on letterhead contributes (semantically) to the authority of the communication. I can understand then why you might want to encode the printed letterhead "inline", and perhaps there is something more meaningful in your project than the official institutional ethos afforded by specially printed paper. But I think I would be drawn to including the letterhead information and description much the way we currently handle postmarks, wax seals, and watermarks in my (19th-c.) Digital Mitford project, and that is by tucking the details in the TEI header in the supportDesc, as information about the supporting material on which the document is printed that tells us about the paper and resources used (literally) to *support* the document. I think much would depend on how incidental or semantically important the letterhead content is in the project you're developing, and I just wanted to trot supportDesc out as an option to consider. 

I'm refraining from indicating exactly where in the supportDesc the rendering of letterhead contents might go because I've never coded letterhead before and I'd need to spend a lot of time meditating over the Guidelines to work it out, but my tendency would be to find a way to encode the letterhead such that it doesn't seem part of the semantic flow of the letter's contents. Treating it as a figure makes sense, but how literally does the encoding need to mimic the physical page layout? 

Cheers,
Elisa
--
Elisa Beshero-Bondar, PhD 
Director, Center for the Digital Text
Associate Professor of English 
University of Pittsburgh at Greensburg
150 Finoli Drive, Greensburg, PA 15601 USA
E-mail: [hidden email] | Development site: http://newtfire.org

Typeset by hand on my iPad

On Feb 23, 2017, at 6:38 AM, Ron Van den Branden <[hidden email]> wrote:

Hi Paul and Peter,

Many thanks for your replies, I'll comment on both here.

Thanks, Paul, for correcting my limited assumptions about <head>, and pointing me to the corresponding <trailer> element. I agree they make an appealing pair for encoding letterheads occurring at the start and end of a letter.

Peter, your proposal is elegant and tempting as well.

Yet, what about letters written on multiple pages, each containing a letterhead (and not necessarily the same)? I think this would make both approaches less straightforward. For the sake of the argument, I'll assume the structure of a 2-page letter, both containing a leading and trailing letterhead.

-<head> / <trailer>: since they can't be intermingled with <p>'s, each page would have to be transcribed in a separate <div>, instead of being marked with <pb/>:

 <div type="letter">
   <div type="page">
     <head type="letterHead">...</head>
     <opener>...</opener>
     <p>...</p>
     <trailer type="letterHead">...</trailer>
   </div>
   <div type="page">
     <head type="letterHead">...</head>
     <p>...</p>
     <closer>...</closer>
     <trailer type="letterHead">...</trailer>
   </div>
 </div>

This wrapping of pages in <div>s seems to go against the logical content of the document, especially when a paragraph is split over a page boundary (which has been the motivation for <pb/>).

-<div type="letterHead">: this would require the <div type="letterBody"> to be split for each new page:

 <div type="letter">
   <div type="letterHead">...</div>
   <div type="letterBody">
     <opener>...</opener>
     <p>...</p>
   </div>
   <div type="letterHead">...</div>
   <pb/>
   <div type="letterHead">...</div>
   <div type="letterBody">
     <p>...</p>
     <closer>...</closer>
   </div>
   <div type="letterHead">...</div>
 </div>

I can imagine that both could be linked with @next / @prev, but still it seems highly artificial.

OTOH, and that's what I like about the flexibility of <figure>, this is perfectly valid:

 <div type="letter">
   <figure type="letterHead">...</figure>
   <opener>...</opener>
   <p>...</p>
   <figure type="letterHead">...</figure>
   <pb/>
   <figure type="letterHead">...</figure>
   <p>...</p>
   <closer>...</closer>
   <figure type="letterHead">...</figure>
 </div>

I had to argue with myself about the <figure>-ness of letterheads, but the fact that they're typically the result of a lay-out process in the design of the letter paper seems to be an argument in favour.

Best,

Ron

On 22/02/2017 16:52, Peter Stadler wrote:
Hi Ron,

it would mean a little restructuring but what about
<div type="letter">
    <div type="letterHead"/>
    <div type="letterBody"/>
</div>

Best
Peter

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: correspondence encoding problems: letter headings

Conal Tuohy-3
In reply to this post by ron.vandenbranden
Ron, your example of letters containing multiple letterheads reminded me to suggest the use of <fw> ("forme work")



The fw element may be used to encode any of the unchanging portions of a page forme, such as:
  • running heads (whether repeated or changing on every page, or alternating pages)
  • running footers
  • page numbers
  • catch-words
  • other material repeated from page to page, which falls outside the stream of the text
Because it's a member of the model.global class, you may deploy it freely!



Conal


 

On 23 February 2017 at 21:38, Ron Van den Branden <[hidden email]> wrote:
Hi Paul and Peter,

Many thanks for your replies, I'll comment on both here.

Thanks, Paul, for correcting my limited assumptions about <head>, and pointing me to the corresponding <trailer> element. I agree they make an appealing pair for encoding letterheads occurring at the start and end of a letter.

Peter, your proposal is elegant and tempting as well.

Yet, what about letters written on multiple pages, each containing a letterhead (and not necessarily the same)? I think this would make both approaches less straightforward. For the sake of the argument, I'll assume the structure of a 2-page letter, both containing a leading and trailing letterhead.

-<head> / <trailer>: since they can't be intermingled with <p>'s, each page would have to be transcribed in a separate <div>, instead of being marked with <pb/>:

  <div type="letter">
    <div type="page">
      <head type="letterHead">...</head>
      <opener>...</opener>
      <p>...</p>
      <trailer type="letterHead">...</trailer>
    </div>
    <div type="page">
      <head type="letterHead">...</head>
      <p>...</p>
      <closer>...</closer>
      <trailer type="letterHead">...</trailer>
    </div>
  </div>

This wrapping of pages in <div>s seems to go against the logical content of the document, especially when a paragraph is split over a page boundary (which has been the motivation for <pb/>).

-<div type="letterHead">: this would require the <div type="letterBody"> to be split for each new page:

  <div type="letter">
    <div type="letterHead">...</div>
    <div type="letterBody">
      <opener>...</opener>
      <p>...</p>
    </div>
    <div type="letterHead">...</div>
    <pb/>
    <div type="letterHead">...</div>
    <div type="letterBody">
      <p>...</p>
      <closer>...</closer>
    </div>
    <div type="letterHead">...</div>
  </div>

I can imagine that both could be linked with @next / @prev, but still it seems highly artificial.

OTOH, and that's what I like about the flexibility of <figure>, this is perfectly valid:

  <div type="letter">
    <figure type="letterHead">...</figure>
    <opener>...</opener>
    <p>...</p>
    <figure type="letterHead">...</figure>
    <pb/>
    <figure type="letterHead">...</figure>
    <p>...</p>
    <closer>...</closer>
    <figure type="letterHead">...</figure>
  </div>

I had to argue with myself about the <figure>-ness of letterheads, but the fact that they're typically the result of a lay-out process in the design of the letter paper seems to be an argument in favour.

Best,

Ron


On 22/02/2017 16:52, Peter Stadler wrote:
Hi Ron,

it would mean a little restructuring but what about
<div type="letter">
     <div type="letterHead"/>
     <div type="letterBody"/>
</div>

Best
Peter




--
@conal_tuohy
+61-466-324297
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: correspondence encoding problems: letter headings

James Cummings-4
Reading through this thread I was going to suggest the same
thing.  It seems to me that printed letterHeads (and indeed
letterFooters) that appear on every page are just like running
heads in a book.

So something like:

          <div type="letter">
            <pb n="1"/>
            <fw type="letterHead">...</fw>
            <opener>...</opener>
            <p>....</p>
            <p>....</p>
            <fw type="letterfooter">...</fw>
            <pb n="2"/>
            <fw type="letterHead">...</fw>
            <p>....</p>
            <p>....</p>
            <closer>...</closer>
            <fw type="letterfooter">...</fw>
          </div>

Would do a letter with letterhead and letterfooter on each of two
pages (whether identical or different) with openers, closers, etc.

-James

On 23/02/17 13:23, Conal Tuohy wrote:

> Ron, your example of letters containing multiple letterheads
> reminded me to suggest the use of <fw> ("forme work")
>
> *http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-fw.html*
> *
> *
> *Quoting from
> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/PH.html#PHSK*
> *
> *
>
>     The fw
>     <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-fw.html> element
>     may be used to encode any of the unchanging portions of a
>     page forme, such as:
>
>       * running heads (whether repeated or changing on every
>         page, or alternating pages)
>
>       * running footers
>
>       * page numbers
>
>       * catch-words
>
>       * other material repeated from page to page, which falls
>         outside the stream of the text
>
> Because it's a member of the model.global class, you may deploy
> it freely!
>
>
>
> Conal
>
>
>
> On 23 February 2017 at 21:38, Ron Van den Branden
> <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi Paul and Peter,
>
>     Many thanks for your replies, I'll comment on both here.
>
>     Thanks, Paul, for correcting my limited assumptions about
>     <head>, and pointing me to the corresponding <trailer>
>     element. I agree they make an appealing pair for encoding
>     letterheads occurring at the start and end of a letter.
>
>     Peter, your proposal is elegant and tempting as well.
>
>     Yet, what about letters written on multiple pages, each
>     containing a letterhead (and not necessarily the same)? I
>     think this would make both approaches less straightforward.
>     For the sake of the argument, I'll assume the structure of
>     a 2-page letter, both containing a leading and trailing
>     letterhead.
>
>     -<head> / <trailer>: since they can't be intermingled with
>     <p>'s, each page would have to be transcribed in a separate
>     <div>, instead of being marked with <pb/>:
>
>       <div type="letter">
>         <div type="page">
>           <head type="letterHead">...</head>
>           <opener>...</opener>
>           <p>...</p>
>           <trailer type="letterHead">...</trailer>
>         </div>
>         <div type="page">
>           <head type="letterHead">...</head>
>           <p>...</p>
>           <closer>...</closer>
>           <trailer type="letterHead">...</trailer>
>         </div>
>       </div>
>
>     This wrapping of pages in <div>s seems to go against the
>     logical content of the document, especially when a
>     paragraph is split over a page boundary (which has been the
>     motivation for <pb/>).
>
>     -<div type="letterHead">: this would require the <div
>     type="letterBody"> to be split for each new page:
>
>       <div type="letter">
>         <div type="letterHead">...</div>
>         <div type="letterBody">
>           <opener>...</opener>
>           <p>...</p>
>         </div>
>         <div type="letterHead">...</div>
>         <pb/>
>         <div type="letterHead">...</div>
>         <div type="letterBody">
>           <p>...</p>
>           <closer>...</closer>
>         </div>
>         <div type="letterHead">...</div>
>       </div>
>
>     I can imagine that both could be linked with @next / @prev,
>     but still it seems highly artificial.
>
>     OTOH, and that's what I like about the flexibility of
>     <figure>, this is perfectly valid:
>
>       <div type="letter">
>         <figure type="letterHead">...</figure>
>         <opener>...</opener>
>         <p>...</p>
>         <figure type="letterHead">...</figure>
>         <pb/>
>         <figure type="letterHead">...</figure>
>         <p>...</p>
>         <closer>...</closer>
>         <figure type="letterHead">...</figure>
>       </div>
>
>     I had to argue with myself about the <figure>-ness of
>     letterheads, but the fact that they're typically the result
>     of a lay-out process in the design of the letter paper
>     seems to be an argument in favour.
>
>     Best,
>
>     Ron
>
>
>     On 22/02/2017 16:52, Peter Stadler wrote:
>
>         Hi Ron,
>
>         it would mean a little restructuring but what about
>         <div type="letter">
>              <div type="letterHead"/>
>              <div type="letterBody"/>
>         </div>
>
>         Best
>         Peter
>
>
>
>
> --
> Conal Tuohy
> http://conaltuohy.com/
> @conal_tuohy
> +61-466-324297


--
Dr James Cummings, [hidden email]
Academic IT Services, University of Oxford
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: correspondence encoding problems: letter headings

ron.vandenbranden
Administrator
In reply to this post by Elisa Beshero-Bondar-2

Hi Elisa,

Thanks for your suggestion! I'm very much aware of the tension between transcription of logical units vs diplomatic "accidentals", this issue touches upon. We're still shaping the encoding guidelines for this project, and I'm not sure how desirable (and (resource-)wise) it will be to really transcribe the letterhead information in place for a couple of thousand letters. Still, if the project partners think it will be important to include them with the transcription, it would be comfortable to have a solution available.

I fully agree that abstracting this information into a meta-description in the header makes much sense, I guess <supportDesc> or <layoutDesc> would be suitable places.

Best,

Ron


On 23/02/2017 13:02, Elisa wrote:
Dear Ron (and Paul and Peter),
The letters I work on aren't on letterhead, but in my university life I am often having to prepare a formal letter to be sent on the stuff, which usually involves a little awareness of spacing on the page and some sense that the printing on letterhead contributes (semantically) to the authority of the communication. I can understand then why you might want to encode the printed letterhead "inline", and perhaps there is something more meaningful in your project than the official institutional ethos afforded by specially printed paper. But I think I would be drawn to including the letterhead information and description much the way we currently handle postmarks, wax seals, and watermarks in my (19th-c.) Digital Mitford project, and that is by tucking the details in the TEI header in the supportDesc, as information about the supporting material on which the document is printed that tells us about the paper and resources used (literally) to *support* the document. I think much would depend on how incidental or semantically important the letterhead content is in the project you're developing, and I just wanted to trot supportDesc out as an option to consider. 

I'm refraining from indicating exactly where in the supportDesc the rendering of letterhead contents might go because I've never coded letterhead before and I'd need to spend a lot of time meditating over the Guidelines to work it out, but my tendency would be to find a way to encode the letterhead such that it doesn't seem part of the semantic flow of the letter's contents. Treating it as a figure makes sense, but how literally does the encoding need to mimic the physical page layout? 

Cheers,
Elisa


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: correspondence encoding problems: letter headings

Elisa Beshero-Bondar-2
Ron— Glad the TEI Header idea is useful! I like the <fw> element best so far as a solution for handling the letterhead inline, but I hope (for ease of handling a large project) that <supportDesc> or <layoutDesc> is deemed an optimal solution. I find myself increasingly thinking about how we deal with the evaluation of how much of a physical document and its supporting materials: Of course these things matter to record, but to follow them in “sequence” poses interesting semantic questions about writing and reading order, and whether we’re encoding primarily the physical details of a document or the communication it facilitates. Always a thorny (and interesting) question of course!

Elisa
-- 
Elisa Beshero-Bondar, PhD
Director, Center for the Digital Text | Associate Professor of English
University of Pittsburgh at Greensburg | Humanities Division
150 Finoli Drive
Greensburg, PA  15601  USA
E-mail:[hidden email]
Development site: http://newtfire.org






On Feb 23, 2017, at 9:03 AM, Ron Van den Branden <[hidden email]> wrote:

Hi Elisa,

Thanks for your suggestion! I'm very much aware of the tension between transcription of logical units vs diplomatic "accidentals", this issue touches upon. We're still shaping the encoding guidelines for this project, and I'm not sure how desirable (and (resource-)wise) it will be to really transcribe the letterhead information in place for a couple of thousand letters. Still, if the project partners think it will be important to include them with the transcription, it would be comfortable to have a solution available.

I fully agree that abstracting this information into a meta-description in the header makes much sense, I guess <supportDesc> or <layoutDesc> would be suitable places.

Best,

Ron


On 23/02/2017 13:02, Elisa wrote:
Dear Ron (and Paul and Peter),
The letters I work on aren't on letterhead, but in my university life I am often having to prepare a formal letter to be sent on the stuff, which usually involves a little awareness of spacing on the page and some sense that the printing on letterhead contributes (semantically) to the authority of the communication. I can understand then why you might want to encode the printed letterhead "inline", and perhaps there is something more meaningful in your project than the official institutional ethos afforded by specially printed paper. But I think I would be drawn to including the letterhead information and description much the way we currently handle postmarks, wax seals, and watermarks in my (19th-c.) Digital Mitford project, and that is by tucking the details in the TEI header in the supportDesc, as information about the supporting material on which the document is printed that tells us about the paper and resources used (literally) to *support* the document. I think much would depend on how incidental or semantically important the letterhead content is in the project you're developing, and I just wanted to trot supportDesc out as an option to consider. 

I'm refraining from indicating exactly where in the supportDesc the rendering of letterhead contents might go because I've never coded letterhead before and I'd need to spend a lot of time meditating over the Guidelines to work it out, but my tendency would be to find a way to encode the letterhead such that it doesn't seem part of the semantic flow of the letter's contents. Treating it as a figure makes sense, but how literally does the encoding need to mimic the physical page layout? 

Cheers,
Elisa



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: correspondence encoding problems: letter headings

ron.vandenbranden
Administrator
In reply to this post by Conal Tuohy-3

Hi Conal,

(Wow, it feels like you've kindly bumped me over the end tag of a nasty <blindspot> element I'd been trapped in, thanks!)

<fw> looks very suitable. While its content model is quite limited, it can contain elements like <address> and <figure>, which seem to be frequent components of letterheads. I'll definitely give this closer consideration.

Best,

Ron

On 23/02/2017 14:23, Conal Tuohy wrote:
Ron, your example of letters containing multiple letterheads reminded me to suggest the use of <fw> ("forme work")



The fw element may be used to encode any of the unchanging portions of a page forme, such as:
  • running heads (whether repeated or changing on every page, or alternating pages)
  • running footers
  • page numbers
  • catch-words
  • other material repeated from page to page, which falls outside the stream of the text
Because it's a member of the model.global class, you may deploy it freely!



Conal


Loading...