#324 Allow certainty etc. inside milestoneLike elements
I would like to suggest that certainty and similar elements (certainty, precision and respons) be able to appear inside otherwise empty elements such as model.milestoneLike, so as to take advantage of the ability to use relative XPath in @match to point to a parent element (and some @locus of that element). (See http://purl.org/TEI/FR/2862151 for this feature applied to other "empty" elements...)
The specific use-case I have in mind is:
<lb n="13"><certainty cert="low" match=".." locus="location"/></lb>
I know you could use either (a) absolute XPath in @match, or (b) a stand-off pointer to an xml:id in @target, but since the functionality of @match exists, and there are occasions when it is very useful, is there any reason for it not to be available more globally?
I think the possible benefits of adding yet another method of doing this are seriously outweighed by the confusion caused by allowing content (even empty content) inside previously empty elements. Just think of the number of stylesheets which will fall over and die. If you want to say that the location of an <lb/> is uncertain, surely it's easier to do that by proposing an attribute on the <lb/>.
I don't think any of my stylesheets would die from finding unexpected content inside an "empty" element--surely if it's not expecting content it will just ignore that content.
This is the same argument we had for <gap/> and <space/> (etc.) which have always been "empty" elements (and arguably still are in the philosophical sense that they don't contain any transcriptional content). Adding an attribute such as @uncertainLocation="yes" to <lb/> wouldn't address the wider issue which is being able to express uncertainty (and/or precision) about any aspect of the element or its attributes. "This is the beginning of line 17 in #Goodchild's edition, and maybe Mommsen's." (Some older editions are pretty flaky in how consistently they represent this sort of thing.)
I'm just trying to take advantage of the (relatively) new @match=".." feature of <certainty> and friends, and the door it opens for much simplified representation of complex/arbitrary uncertainty. Could we put this on the table for discussion at Ann Arbor?
While we're at it, we could address the issue that the example given for the use of @match doesn't actually have @match in it:
http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/ref-att.scoping.html
GB will survey the guidelines to see what kind of changes this would involve. He will report back via email, unless there is great disagreement the FR should be approved and implement. If there is disagreement, address at our next teleconference
Sorry, but I am still unconvinced. Remind me again why the generic standoff mechanism is not an acceptable solution to all these problems? It seems to me that 99% of people using empty elements expect them to be empty, and write processors which do the same. (The cases of <gap> and <space> are special -- the information formerly provided as attributes must be provided somewhere, and provision as content is therefore anticipated). It also seems to me that the ability to mark uncertainty and imprecision for any aspect of any element is already provided for by existing standoff mechanisms. I'd be reluctant to make this change without better examination of some specific real cases. For example, if you want to say this <lb/> is definitely here in Mark's edition and may be here in Spencer's, what's wrong with putting in two <lb/>s with different @cert values ?
For the record, GB's survey is at http://lists.village.virginia.edu/pipermail/tei-council/2012/015996.html .
This was discussed in some detail at the last Council F2F, and I thought Lou had withdrawn his objections on that occasion, but I'll try to reconstruct some of the arguments here, for the record.
(1) The issue with empty elements being expected to be empty is a fair point, but I think it applies more to the presence of text-containing elements such as <desc> or <gloss>, which I agree we don't need in milestoneLike and other empty elements. But having an empty element such as certainty/precision/respons inside <lb> is not especially confusing, and I can't see any way that this would break processes that don't expect them--at worst they'd be ignored. An element like this inside another element is just a form of enhanced attribute, really. (And if you don't like it, then you don't have to use it, or you can cleanly remove the possibility in your ODD.)
(2) There are several different kinds of uncertainty that might be expressed about (e.g.) an <lb> other than merely that it might or might not be in the right place for a given edition. The lb element bears several attributes, including @n, @corresp, @break, @ed, and I've had cause to hedge all of these on occasion, and more importantly to offer alternative possible values using the @assertedValue attribute of <certainty/>. Contrary to Lou's assertion, I don't know how I would interpret @cert on <lb/>; it could mean too many different things. To take another example, a certainty declaration pointing to a <handShift> element could refer to the location of the hand-shift, its very existence, the identity of the new hand starting here, the scribe/script/medium, etc. (And again, alternative values may be offered.)
(3) It is true of course that there is already a way to do this using a stand-off <certainty/> pointing to an @xml:id on the target element. But the @match atribute on certainty/precision etc. was deployed a few releases ago because it was felt (and I still maintain it is the case) that it is easier both for a human and in certain editing environments to write and interpret
<gap><certainty match=".."/></gap>
than
<gap xml:id="g0097356"/> <!--arbitrary distance later--> <certainty target="#g0097356"/>
Far from creating chaos by introducing a new way to mark uncertainty, the change proposed in this ticket is actually creating further consistency by allowing this already-existing method for pointing to a target element to be used more universally. (I would like, for example, to use certainty/@match for all occurances of certainty across a given project, rather than @match in some cases and standoff @target in others where the schema does not allow it.)
The proposal sent to the Council mailing list, and expanded by Kevin, is to add these three elements to the content model of the milestoneLike elements (cb, gb, lb, milestone, pb), transcriptional elements (caesura, handShift, pause, redo, shift, undo, move), spanning elements (addSpan, anchor, damageSpan, delSpan, lacunaEnd, lacunaStart, witEnd, witStart) and dictionary elements (oRef, pRef). While the real-world use-cases so far adduced are restricted to milestoneLike elements, the survey of all empty elements was requested presumably because it is always better to introduce a change to the TEI in a consistent and coherent way than to introduce a one-off patch to a single element per use-case.
Apologies for being still unconvinced, but for the record here are my responses on these 3 points:
1. I agree that the situation is slightly less confusing iif the intention is to permit only some specific elements (all of which are empty) within some other specific empty elements. In which case we should define a new class ( "model.metaMark" anyone?) and revise the content models for the proposed elements from (EMPTY) to (model.metaMark*)
2. @cert is about the certainty of the assertion expressed by the element to which it's attached -- not any particular attribute of it. Hence my suggestion that when it appears on an <lb/> it can only relate to the whole of the information conveyed by that element, and the possibility of repeating that element if different aspects have different degrees of certainty, as in my Marks and Spencer example below.
3. Gabby says
"it is easier both for a human and in certain editing environments to write and
interpret <gap><certainty match=".."/></gap>
than <gap xml:id="g0097356"/> <!--arbitrary distance later--> <certainty
target="#g0097356"/>"
But if the distance is arbitrary it might be zero. In which case, I cannot see much distinction between
<gap><certainty match=".."/></gap>
and
<gap xml:id="g0097356"/> <certainty target="#g0097356"/>
other than the need for an identifier and the link to it. I can't imagine anyone doing this kind of markup manually so is that really such an overhead?
In any case, the major point of controversy here seems to be whether the existing standoff solution is really annoying enough to warrant the fairly major upheaval being proposed by this ticket.
Regarding the recent addition of <certainty>, <precision>, <respons>, etc. to <gap> and <space>, Lou wrote below that "the information formerly provided as attributes must be provided somewhere, and provision as content is therefore anticipated". But couldn't the same be said about the changes in this ticket if it were adopted? This request and the recent addition of children to <gap> and <space> seem quite similar to me (as they apparently do to Gabby) since we are proposing to add the same child elements, and I don't understand why we would treat them differently.