#492 Allow bibl inside app

[Hugh A. Cayless]

[Note: this ticket was originally two tickets, 491 and 492. Merged by MDH 2014-07-30.]

FIRST:

The content model for <app> allows <wit> inside it to permit the encoding of sigla in a print apparatus. This corresponds to the machine-actionable references to witnesses using @wit. The next release of the Guidelines will allow @source on <rdg> (see [feature-requests:#465]), so it seems reasonable also to permit <bibl> inside <app> to allow bibliographic citations of sources in apparatus to be encoded properly.

For example in the following bit of apparatus:

9 latebit FTX 11 gelidas…oras Eutyches, G. L. K. v. 475
12 suo BP Eutyches 14 n. n.] verba canina (carina Zamoscianus)
FTX cod. Zamoscianus etc.

"G. L. K. v. 475" cites page 475 of Keil's Grammatici Latini, so it would be reasonable to put it in a <bibl>, something like:

<app><ref target="#l11">11</ref> <rdg source="#GLK">gelidas...oras</rdg> 
<wit>Eutyches, </wit><bibl>G. L. K. v. 475</bibl></app>

SECOND:

Printed apparatus critici often include a reference to the line number in the text that the apparatus entry applies to. This seems like it really ought to be encoded as a <ref>. For example, if I want to encode a print apparatus looking like:

9 latebit FTX 11 gelidas…oras Eutyches, G. L. K. v. 475
12 suo BP Eutyches 14 n. n.] verba canina (carina Zamoscianus)
FTX cod. Zamoscianus etc.

(from the first page of Owen's edition of Ovid's Ibis) I might want to treat the line numbers as references to the line, but I can't use <ref> inside <app>. I want to be able to do something like:

<app><ref="#l9">9</ref><rdg wit="#F #T #X>latebit</rdg> <wit>FTX</wit></app>

to represent the line refs in the app.

Note: see also [feature-requests:#521].

[James Cummings]

Assigning to myself to triage and report to council

[Martin Holmes]

First, I would recommend that this FR and 491 be folded together; they suggest very similar sorts of modification to the content model of <app>, and it'll be easier to keep the discussion on track if comments are not split across two tickets. James, since you're the owner of both tickets, do you agree?

Second: there was a useful discussion of this ticket at the FTF in Oxford in July 2014, in which one issue that arose was this:

Some believe that <app> and friends should only be used to encode new (i.e. born-digital) critical apparatus, while others believe it should also be appropriate to use <app> to encode both new apparatus and to encode a transcription of an existing print critical edition. The Guidelines chapter example based on Klaeber's Beowulf edition would seem unequivocally to support the latter view (http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCAPLR). I think a final decision on this is essential before moving forward with these tickets; the need for the requested elements arises out of the encoding of an existing print apparatus.

If we do believe that <app> should do both jobs, then we will most likely face a slow accumulation of feature requests for more elements that need to be included in its content model. For this reason, the Council discussion gave rise to a proposal that we create model.appPart, and rationalize the content model of <app> to use that rather than the quite complicated and confusing content model it currently has. This will not be simple, because of the need to maintain backward compatibility.

[James Cummings]

1) Yes. Fold together/merge ... can we do that easily in sourceforge these days? If so, please feel free to, Or I'll investigate in a few days.
2) Yes the latter view was always the original intention, I think and the source of the underlying tension. (Similarly in many other parts of the TEI).
3) We only really need to keep backwards compatibility with at all vaguely sane things allowed in there, IMHO.

[Martin Holmes]

I've now merged the two tickets and closed 491.

[Martin Holmes]

See https://sourceforge.net/p/tei/feature-requests/521/ which is related to this.

[James Cummings]

Prod JC to do.

[Hugh A. Cayless]

I suggest we wait on this until the App. Crit. group has a chance to review the next draft proposal.

[James Cummings]

If this is done it should be done together with other app crit changes in a consistent manner.