#434 content model of <front> does not allow <epigraph> at the en

GREEN
closed-accepted
None
5
2013-04-13
2013-02-09
Sebastian Rahtz
No

broadly speaking, <front> ,<body> and <back> look the same. However, at their end, they vary: <body> uses
model.divBottom ("groups elements appearing at the end of a text division"), while <front> and <back> use
model.divBottomPart ("groups elements which can occur only at the end of a text division"). In fact, one encompasses
the other, which is sort of OK (though the descriptions are then confusingly similar), but the effect is that
all of the following: "meeting byline dateline argument epigraph salute docAuthor docDate" can only occur
at the end of <body>, not of <front>. Its hard to defend this.

EEBO A12096 (STC 22399) has an example of an epigraph (conveniently labelled "Epigramma de Miraculis Antichristi.") at the end of its (clear) <front>

Unfortunately, there is not a simple solution. These content models are horribly complicated. <front> has no mandatory content at all, so ambiguous content models result only too easily.

Discussion

  • Lou Burnard
    Lou Burnard
    2013-03-13

    Presumably our goal should be to make <front> <body> and <back> all behave in the same way?

     
    Last edit: Lou Burnard 2013-03-13
  • Yes. Unless you can come up with a convincing differentiation between them. are there definitively things which can only appear in back or front, or body?

     
  • Lou Burnard
    Lou Burnard
    2013-03-30

    I think <titlePage> probably appears only in <front> or <back> However I happen to know you've developed a much better content model for tcp.odd, so why don't we just plug that in here, declare victory, and move on?

     
    Last edit: Lou Burnard 2013-03-30
  • Lou Burnard
    Lou Burnard
    2013-03-30

    • status: open --> open-accepted
    • milestone: --> GREEN
     
  • I have the candidate replacement content model ready to go; I will now try it on the whole guidelines and its test files

     
  • Kevin Hawkins
    Kevin Hawkins
    2013-04-08

    • assigned_to: Sebastian Rahtz
     
    • status: open-accepted --> open
     
    • status: open --> closed-accepted