#320 content model of <signed>

GREEN
closed-fixed
5
2012-10-22
2011-11-18
Sebastian Rahtz
No

There are a number of occurences in TCP ECCO texts of <list> inside <signed>. I'd like to change the content model
of <signed> to be macro.paraContent instead of macro.phraseSeq. This makes sense, as <signed> is a sibling of <p>
and a child of <div>

Example:
<closer>
<signed>Sign'd and Seal'd,
<list><item>John Bull,</item><item>Nic. Frog.</item></list>
</signed>
</closer>

Discussion

  • James Cummings
    James Cummings
    2011-11-18

    Given the huge number of other inappropriate things I can use inside <signed> .... I don't see that this makes that much difference.

    +1 from me.

     
  • Kevin Hawkins
    Kevin Hawkins
    2011-11-19

    +1.

    Lots of texts (such as the US Declaration of Independence) are signed by more than one person. Whether their names are listed in one more more columns or just separated by commas within run-on text (see P5 section 3.7) is immaterial; what you have is a list.

     
  • Lou Burnard
    Lou Burnard
    2011-11-19

    What semantics are you proposing for this element, since the Guidelines are bit unclear on the subject (cf my comments on TEI-L)? If it's just "closer with a signature in it" I can't see why it's useful.

     
  • James Cummings
    James Cummings
    2011-11-22

    In rereading the thread on the council list, looking at the examples in the Guidelines and
    elsewhere I believe that the intention of <signed> is to function both
    as a phrase and as a block level element. In this way it is very much
    like <list> itself, which can be inline in a pararaph, or a sibling to a
    paragraph. <signed> can be a sibling to a paragraph (at the bottom of a
    div) and is joined in model.divBottom with <trailer>, <closer>, and
    <postscript>. <signed> can I was surprised to see that neither <trailer>
    nor <closer> allow a <list> child either, but that <postscript> does.
    This is because <postscript> is sort of like a <div> in that it can
    contain paragraphs (and thus things like <list> which appear between
    paragraphs) whereas the others are like things which appear inside
    <div>s. I realise I'm repeating the obvious here, I'm just thinking things through.

    The current content models, ignoring attribute classes, are:

    signed: macro.phraseSeq
    trailer: macro.phraseSeq
    macro.phraseSeq=(text|model.gLike|model.phrase|model.global)*
    closer: (text|model.gLike|model.phrase|model.global|signed|dateline|salute)*
    postscript: ((model.common)|(model.global))*

    So <closer> is exactly the same as <signed> or <trailer> except that we
    have specifically added <signed>, <dateline>, and <salute> to this to
    allow it to group them. This, and the examples, encourages me in my
    conclusion that we have intended <signed> to function either as
    surrounding a single signature or as a signature block containing the
    closing salutation text as well as the signature. Partly because of
    this, and partly because of the examples given, I find the argument for
    including list (or model.listLike) generally persuasive.

    Although I'm loathe to recommend further opening the floodgates of
    bizarre stuff that is allowed in inappropriate places, the only
    difference between the content model of a paragraph, and that of
    <signed> and <trailer> (and arguably <closer>) is that a paragraph also
    allows model.inter (which has elements which appear either within or
    between paragraphs, like lists).

    macro.phraseSeq=(text|model.gLike|model.phrase|model.global)*
    macro.paraContent=(text|model.gLike|model.phrase|model.global|model.inter)*

    If we changed <signed> and <trailer>'s content model to
    macro.ParaContent this would allow <list> there, and have no
    backwards-compatibility implications. We could change <closer> to be the
    same but with signed|dateline|salute as it currently has. I'd recommend
    changing both <signed> and <trailer> in tandem for consistency between
    elements in model.divBottom but I could be argued out of that.

    However, I'd suggest that we explain that <signed> can be used both as a
    single signature and as a block containing salutation text and
    signature(s), but that the better encoding is to use <closer> with
    <salute> for the salutation text if possible. Both its description and
    discussion in the prose of the Guidelines should make this clear.

    My two pence,

    -James

     
  • Lou Burnard
    Lou Burnard
    2011-11-22

    Might it not be better to retain <signed> as a phrase level element meaning precisely "signature", and add a new inter-level element called <sigBlock> or something? Just shovelling more into an already imprecisely defined element doesn't seem right.

     
  • Adding <signedBlock> would be possible, I agree.Alternatively, we could
    expand the existing <signed> to do that job, and thus keep compatibility with
    existing extended use of <signed>, and add <signame> to do the more precise job.

    One could argue that TEI is already awash with "shovelling more into an already imprecisely defined element" :-} (<timeline> inside <signed>, anyone?)

     
  • Lou Burnard
    Lou Burnard
    2011-11-22

    One could argue that, but I am glad one is not doing so, particularly in this case, since signatures are very frequently dated. And as I am sure you have had occasion to remark to your offspring occasionally "two wrongs don't make a right".

     
  • Martin Holmes
    Martin Holmes
    2011-11-22

    I don't like the idea of adding new elements to get around what is essentially an issue of over-looseness; we can avoid Birndoom while promoting good practice just by deciding how we think all the <closer> stuff should be constructed, and then making sure all our examples and explanatory text show and encourage that. Regarding <sigName> specifically, what's wrong with <name> inside <signed>?

    Basically we need to decide whether such things as <name> and <date> belong inside <signed>, or whether <signed> is just syntactic sugar for <name type="signature">. If <signed> should contain elements like <name>, then I think it's clear that it can contain more than one of them; and in that case, there's no reason why it shouldn't contain a <list> of them.

     
  • Lou Burnard
    Lou Burnard
    2011-11-22

    Sample signatory phrases (or blocks) from PFS

     
    Attachments
  • Lou Burnard
    Lou Burnard
    2012-03-18

    • milestone: 871213 --> 871214
     
  • James Cummings
    James Cummings
    2012-04-15

    Increasingly I think that we should define <signed> as the signtature block, and just use <name> inside it for the actual signatures.

     
  • James Cummings
    James Cummings
    2012-09-19

    Council agress to change the content model of signed to macro.paraContent (double check this!) (face to face 2012-09); and rationalize all current examples to a single practice and add one with list inside signed.

     
  • James Cummings
    James Cummings
    2012-09-19

    • milestone: 871214 --> GREEN
    • status: open --> open-accepted
     
  • now in place

     
    • status: open-accepted --> closed-fixed