#468 Order of elements in publicationStmt

AMBER
closed-fixed
1(low)
2014-09-08
2012-11-06
No

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.

Discussion

<< < 1 2 (Page 2 of 2)
  • Sebastian Rahtz

    Sebastian Rahtz - 2014-01-05

    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

    Syd Bauman - 2014-01-07

    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

    Syd Bauman - 2014-09-08
    • status: open-accepted --> closed-fixed
     
  • Syd Bauman

    Syd Bauman - 2014-09-08

    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.

     
<< < 1 2 (Page 2 of 2)

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks