#468 Order of elements in publicationStmt

[John P. McCaskey]

A note for publicationStmt says this:

Although not enforced by the schemas, it is a requirement for TEI conformance that information about publication place, address, identifier, availability, and date be given in that order, following the name of the publisher, distributor, or authority concerned

Several examples in 2.2 fail to follow this conformance requirement and I see no note about this discrepancy.

[Kevin Hawkins]

I'm shocked to report that this statement and the examples that don't correspond to it have both been in the TEI Guidelines since at least P3. I don't know what the rationale was for requiring that the child elements occur in that order, and given the long-standing examples that don't use that order, I would support removing this requirement. Still, if we kept the order requirement, I wonder whether we could replace model.publicationStmtPart with a more complicated content model for <publicationStmt> that would in fact enforce the desired order. (I assume the order wasn't enforced in the earliest TEI DTDs.)

The TEI Technical Council will discusss ...

[Sebastian Rahtz]

I can see why this was said, enforcing normalization in metadata is good. But I also see that a more specific and complex content model would break what we generally try to do with model classes, ie not mention elements by name. We could I suppose add some schematron, or make up more granular model classes,

I feel entirely evenly balanced on the subject, could vote ether way. But. I agree we should go entirely one way ir the other.

[Sebastian Rahtz]

I can see why this was said, enforcing normalization in metadata is good. But I also see that a more specific and complex content model would break what we generally try to do with model classes, ie not mention elements by name. We could I suppose add some schematron, or make up more granular model classes,

I feel entirely evenly balanced on the subject, could vote ether way. But. I agree we should go entirely one way ir the other.

[Syd Bauman]

My first instinct is that there is absolutely no need to constrain
the order of publication place, address, identifier, availability, and
date, but it is very important to associate those details with the
publisher, distributor, or authority concerned. In the current model,
this is done by having the publication place, address, identifier,
availability, or date immediately follow the publisher, distributor,
or authority to which it applies.
Personally I don't like this. I prefer containment. Thus I have
suggested before, and will suggest again, that <publisher>,
<distributor>, and <authority> should contain the publication place,
address, identifier, availability, or date elements that apply to
them. I.e., instead of macro.phraseSeq, their content model would be
something like ( model.nameLike.agent, model.newclass* ), where the
new class has <pubPlace>, <idno>, <availability>, <address>, and <date> is its members.
Thus we'd see things like

    <distributor>
      <orgName>Brown University Women Writers Project</orgName>
      <availability>
        <license>CC3 blah blah</license>
      <availability>
      <date when="2013-04-10"/>
    </distributor>

Note that this completely breaks the model that
<distributor>...</distributor> is syntactic sugar for

<respStmt><resp>distribution</resp><name>...</name></respStmt>, 

which
some subscribe to. It also breaks existing P5 documents.
So, unless Council thinks this is important enough to break existing
documents, we need to come up with a backwards-compatible solution.
Sebastian's analysis that a specific content model would break what we
try to with classes is correct. Doesn't bother me much. That said,
since I don't think the order of the detail elements (<pubPlace>,
<idno>, <availability>, <address>, and <date>) is important, I'd be
happy with
( ( ( model.A, model.B )+, model.pLike ) | model.pLike+ )
where
model.A = ( publisher | distributor | authority )
model.B = ( pubPlace | idno | availability | address | date )
This enforces the important part, does not enforce the unimportant
part (which should be removed from the prose, too, of course), and
leverages the class system (i.e., does not directly mention elements
in content model). And I'm pretty sure it's deterministic, so won't
break DTDs.

[Lou Burnard]

Sorry Syd but there is a good reason to constrain the order of publication place, address, identifier, availability, and date as children of this particular element, precisely because they may be repeated and there is no grouping element to indicate where the repetition starts. Maybe there should be such an element, but there isn't at present and that's not what the ticket proposes. Instead, and as agreed at the Council meeting, the action should be (a) to clarify in the prose that the sequencing requirement applies only in the case where the element contains elements other than <p> and (b) to check practice in the Guidelines for conformity with this requirement.

Here's the rewording I have just made:

Where a publication statement contains several members of the mode.publicationStmtPart class rather than one or more paragraphs, care should be taken to ensure that the repeated elements are presented in a meaningful order. It is a conformance requirement that elements supplying information about publication place, address, identifier, availability, and date be given following the name of the publisher, distributor, or authority concerned, and preferably in that order. These constraints are not currently modelled in the schema, but may be in a future release.

[James Cummings]

Have any misleading examples been corrected? What remains to be done on this ticket?

[James Cummings]

At Oxford 2013-11 face-to-face LB admitted that he had misunderstood but that his prose expresses the same thing but noted that we need to test SB’s content model to make sure it’s deterministic. Action: SB will do the content model and LB will do the prose.

[Sebastian Rahtz]

Strikes me this is getting confused. Some people are trying to constrain absolute order, others constrain whether one group of things can occur before another group of things.

You just need to use the sequenceOptional or sequenceOptionalRepeatable prefixes in the <ref> element in the content model of <publicationStmt>, no need to get into new classes, I think.

[Syd Bauman]

Council discussed this back at its face-to-face meeting in Nov, and agreed to the content model proposed here on 2013-04-10.

The content model has been updated as of r12748 of the source. Some of the prose of the GLs has been updated to match, but there is still tidying up to do in the prose. E.g., the prose still asserts that ﹤pubPlace﹥, ﹤address﹥,﹤idno﹥,﹤avail﹥, and ﹤date﹥, must be specified in that order, which the schema does not support. (And personally I see no reason to keep this order, but perhaps someone else knows why it was enforced that way in the first place -- it has been like that since P2.)

Still leaving the ticket open pending some tweaks to the prose of section 2.2.4. Some notes:

• The new content model is slightly different than the one proposed 2013-04-10: that one permitted paragraphs to occur after all of the specialized elements. The new model just introduced continues to enforce the “either all prose or all specialized” division that was enforced in P2, P3, P4, and heretofore in P5. I think this is a bad rule, and will try again to get rid of it in the future.
• Besides not enforcing the order of ﹤pubPlace﹥, ﹤address﹥,﹤idno﹥,﹤avail﹥, and ﹤date﹥ this new content model also does not enforce the number of them. In P2 you were permitted only 0 or 1 each of ﹤pubPlace﹥, ﹤address﹥, ﹤avail﹥, and ﹤date﹥ after a ﹤publisher﹥, ﹤distributor﹥, ﹤authority﹥, but as many ﹤idno﹥s as you wanted. This constraint was not carried forward for three reasons:
  1. First and foremost, AFAIK this restriction was not carried forward into P3. It wasn't reinstated in P4, either, although that does not mean much as P4 dropped many constraints from the DTD that either were not dropped from the prose or (IMHO) should not have been dropped.
  2. Second, the ODD language has no way to express this without dropping down to explicit RELAX NG code, something Council has been trying to avoid.
  3. And third, although the P2 DTD had this restriction, the prose did not mention it.

[Syd Bauman]

This bug has been fixed. Syd Bauman fixed the content model and some of the prose in 2014-01-05/11 with last revision r12774. Lou Burnard polished up the prose 2014-01-12 in revision r12775.