#279 modify postscript

Lou Burnard
Martin Mueller

While transforming EEBO-TCP texts into P5, I have come across many instances where the P5 model for postscript is inadequate. <postscript> does not permit opening and closing elements. But it is not uncommon for a postscript to be a microversion of the letter to which it is appended, with some form of "Dear Sir" and some form of "Sincerely yours, John Smith." Opener and closer elements would be welcome. Right now you would either have to downshift the encoding to <ab> or turn a more complex postscript into floatingText. Neither of these is an attractive solution.


  • Paul Schaffner
    Paul Schaffner

    FWIW, the TCP element that Martin refers to (a local customization which actually predates the P5 element of the same name) has a content model that closely
    matches that of a div7 -- that is, it is basically a div (with divtop and divbottom elements
    allowed), but is restricted by not allowing subdivving, and is further restricted by
    virtue of being allowed only within closer. Its content model, expressed in dtd-talk, is as follows. It is small, of course, because our scheme is in general very much stripped down (or impoverished, if you like).

    <!ELEMENT postscript ((head | opener | lb | milestone | pb | gap)*,
    ((p | l | lg | q | list | letter | license | floatext | note | stage | sp | bibl),
    (lb | milestone | pb | gap)*)+,
    ((closer | tailnote | trailer), (lb | milestone | pb | gap)*)*) >

    ('tailnote' and 'floatext' are other customizations, of self-evident meaning.)


  • Lou Burnard
    Lou Burnard

    When <postscript> was introduced, it was agreed to reserve it for simple postscriupts only, and to represent other more complex structures either with <ab> or with <div>. It is hard to see why a "postscript" should get its own special tag and a "chapter" not -- they are both divs.

  • Martin Mueller
    Martin Mueller

    I see the force of this argument, but it's an even stronger argument for not having postscript in the first place. "postscript" is a part of "letter", and if there is no letter tag why should there be a postscript. So there would be a logic to using <ab> for simple cases and <div> for more complex cases. In the EEBO collection there are things called postscript that are whole treatises, and whatever is the right way of encoding them, <postscript> is not it.

    On the other hand, once you have <postscript>, it's hard not to notice that even short ones are full of openers and closers, salutations, and signatures. So it seems to me that the current content rules for postscript are stuck in an uncomfortable middle, and it might be better either to move back or forward.

    But thinking about this raises broader problems. If you think of elements in very broad terms you might want to get rid of all genre-specific elements. Drama is a relatively privileged genre in TEI (the division of prose, verse, and drama may be an odd reflection of the trinity of epic, drama, and lyric, with its own very genre specific tags. We run into the same inconsistencies. There are no elements for act or scene, but there are elements for prologue and epilogue, and for "speech", although one could made a good case that "said" would do just fine.

    It's tough, and I could see going either way, although I'd probably rather go on a "less is more" path, which might mean abandoning rather than expanding postscript and other elements that sit at a similar level of genre specificity,

    On the other hand, convenience is convenience. If we have <lb> for <milestone unit="line")
    , why not admit the typographical elements of TEI Tite, which let you write y<sup>e</sup> rather than y<hi rend="superscript>e</hi>.

    A lot of ambiguity here that cannot be solved and has to be lived with.

  • Lou Burnard
    Lou Burnard

    Agreed to change content model to (model.divTop|model.global)* , model.common* , ((model.divBottom|model.global)

  • Lou Burnard
    Lou Burnard

    • milestone: 871209 --> GREEN
    • assigned_to: nobody --> louburnard
    • status: open --> pending
    • status: pending --> closed-accepted
  • duly implemented