content model of <signed>

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.

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

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.

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

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

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

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.

Sample signatory phrases (or blocks) from PFS

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

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.

now in place