Re: correspondence encoding problems: letter headings
Paul Schaffner <[email protected]>
| Newsgroups | gmane.text.tei.general |
|---|---|
| Message-ID | <1487777931.2473984.889347608.1DE0AA97@webmail.messagingengine.com> |
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 [email protected] | http://www.umich.edu/~pfs/