Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
"each <app> must contain at least one <rdg>."
Comment: The schema only requires one, but what is a <app> with only one <rdg> (and no <lem>) supposed to mean?
Jens Østergaard Petersen
I suppose one might more accurately require that an app should contain either
(a) one lem and one or more rdgs
or (b) two or more rdgs
The situation arises because some people want to record just <rdg>s without characterising any of them as <lem>s, while others insist on that possibility. If my supposition is correct, the appropriate action would probably be to add a schematron rule to enforce it.
I almost never use <lem> as I don't want to privilege one reading over another in the encoding.... that is what output is for.
I've had <app> with one <rdg> when using nested <app> but only to keep consistency in the markup to make processing easier. (I'm not recommending this as good practice).
Some people like to tessellate <app> entirely over their content even when all witnesses agree. That would be another case one might encounter a single rdg inside an app. I can see the argument that this should be considered poor practice.
The use-case where there's only one <rdg/> is something that we introduced a couple of years ago, to cater for the kind of apparatus that is not strictly variant readings, but possibly attributing the origin of a reading to a given editor or witness without necessarily having to give a lemma or other readings, adding an editorial note to a reading, etc.
I emphatically don't think this is a bug, therefore, even if it's something that _you_ might not want to use in an old-fashioned critical apparatus of variant readings.
As Gabriel says, there are use cases for having just a rdg within an app. We propose to leave the content model unchanged and to add a schematron constraint to check for the existence of at least one rdg.
No, actually I think it was deliberate to allow an <app> with no <rdg> as well. (The use-case envisaged was just a <ptr> [to an app, choice, subst or similar construction in the transcription] and/or a <note> with editorial observations on it.) This again is the case of <app> used for something slightly wider than merely variant readings, as it is in (e.g.) epigraphy, as opposed to MS studies.
Can we revisit this decision, please?
As requested, I'm linking to the discussion in which we made the decisions I'm referring to below (which, it turns out, was way back in 2006-7).
The Sourceforge ticket: http://purl.org/tei/fr/1551357
The TEI-L discussion (2 threads): http://listserv.brown.edu/archives/cgi-bin/wa?A1=ind0607&L=TEI-L#10
Jens Østergaard Petersen
While I can see the use for <app>s with no or only a single <rdg>, my bug report was concerned with the text of the Guidelines, and such uses of <app> are nowhere discussed there. Therefore, until such a discussion is introduced, I would suggest to remove "; each <app> must contain at least one <rdg>", because it introduces the possibility of an <app> containing a single <rdg> (or a <lem> with no <rdg>, I presume), which will be mystifying to those who base themselves on the text of the Guidelines alone. I warmly support Gabriel's 2006 proposal: I see immediate use cases for this.
I agree that there is a problem in the Guidelines here. I suggest that the solution is not to insert a schematron rule to enforce the minimum-one-rdg rule, but to rewrite the guidelines to:
1. remove the statement that at least 1 rdg is required;
2. provide examples of usage of app with less than min <lem>+<rdg>
3. provide examples of usage of app with <ptr> and <note>, both with and without rdg/lem
(I can provide examples of 2+3, but they'll be in Greek and Latin. English examples anyone?)
Council agrees with Gaby's last comment and assigns to him to implement. (face to face 2012-09)
Removed schematron constraint and changed description to read, "with an optional lemma and usually one or more reading or a note on the relevant passage." (at r10988).
Not closing ticket because examples of (2) and (3) below still need added.
Examples of <app> without <lem>, and with <ptr> and <note> added at r12269.
<ptr> and <note>
reopened, because it seems I mistakenly assumed <ptr> was available in <app> whenit has apparently never been. I suppose the function I have imagined for it (i.e. pointing to a choice or app element in the text itself) is more or less covered by @loc? (But @loc isn't a pointer?)
In that case isn't the recommendation to use @from which is a pointer? c.f. http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCAPLN
Right, I was wondering about that, but was put off by the remark "This attribute is only used when the double-end point method of apparatus markup is used", and the examples I'm thinking of use the "location-referenced method". Does this matter?
(If not, should the remark be cleared up a bit?)
I've recast the two examples with @loc or @corresp instead of <ptr>, at r12272
I would vote for the notes on app's @from and @to being changed or removed. I think the prose of the guidelines allows for using them in a location referenced method.
Fair enough. I've changed the example to use @from instead of @corresp (r12273). Do you want to open a new ticket to discuss the GL change, or do that here?
After discussion with the Council, I've changed the wording of those notes slightly to better reflect the reality of how @from is used (as a pointer in location-referenced as well as in double-end point), at [r12278], and am now closing this ticket.