Menu

#279 modify postscript

GREEN
closed-accepted
5
2011-11-08
2011-03-21
No

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.

Discussion

  • Paul Schaffner

    Paul Schaffner - 2011-04-05

    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.)

    pfs

     
  • Lou Burnard

    Lou Burnard - 2011-04-30

    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 - 2011-05-01

    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 - 2011-11-08

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

     
  • Lou Burnard

    Lou Burnard - 2011-11-08
    • milestone: 871209 --> GREEN
    • assigned_to: nobody --> louburnard
    • status: open --> pending
     
  • Sebastian Rahtz

    Sebastian Rahtz - 2011-11-08
    • status: pending --> closed-accepted
     
  • Sebastian Rahtz

    Sebastian Rahtz - 2011-11-08

    duly implemented