[tei-council] empty elements revisited

[Lou Burnard]

On 29/09/11 11:32, Gabriel Bodard wrote:
> That's true, and that's possible already, of course. Two responses to that:
>
> 1. This was also true of gap and space and other elements, and we agreed
> that being able to use the relative XPath content of @match to point to
> a parent element was nonetheless extremely useful. (Indeed, for at least
> one project I know of it is invaluable, because generating and keeping
> stable @xml:ids turned out to be a *very hard* problem in an assisted
> editing environment.) I really really like being able to use
> <certainty/>  et al. contextually rather than as stand-off.

well, i don't particularly want to revisit that long discussion, but 
just for the record, it's not impossible that our previous decision was 
mistaken! (certainly some people said so at the time)

I do wonder whether we'd feel so keen to provide so many *different* 
ways of doing essentially the same thing in these days of minimalism...

The "oh but maintaining xml:ids is just too hard" argument cuts little 
ice with me. You can automate it. Or you don't have to use ids -- you 
can use an xpath or make up your own syntax and use a URN. Something 
along those lines is inevitable in the standoff paradigm which, we are 
always being told, is The One True Way.

>
> 2. Maybe therefore combining certainty/precision with model.glossLike
> wasn't so wise after all. (I note, for example, that the description of
> model.glossLike still says "groups elements which provide an alternative
> name, explanation, or description for any markup construct", which
> doesn't seem to cover certainty/precision very usefully.

however i agree that separating them out of this mix would be a very 
good idea

>
> Could I suggest that the solution is to create a new model for certainty
> and precision (and maybe respons?), which is itself a member of
> glossLike (so that it is available wherever glossLike is), but may be
> included on its own as well (e.g. within milestoneLike elements).
>
> Gabby
>
> On 2011-09-28 18:53, Lou Burnard wrote:
>> The trouble with this is that once you allow model.glossLike elements in
>> general you open the door to all sorts of crud.
>>
>> I imagine that young Stormageddon would throw a fit at the idea of
>> having to process  e.g.
>>
>> <lb><desc>This is a line break I want to discuss for some bizarre
>> reason</desc></lb>
>>
>> and I think I would agree with him.
>>
>> Wouldn't your use case be better met by a stand-off solution? i.e. why
>> not do
>>
>> <lb xml:id="n13"/><certainty cert="low" target="#n13" locus="location"/>
>>
>>
>>
>>
>> On 28/09/11 18:16, Gabriel Bodard wrote:
>>> A couple years ago we had a discussion about adding certainty and
>>> precision to model.glossLike, so that empty elements such as gap and
>>> space could take these as children, and so take advantage of the use of
>>> relative XPath in @match. (Discussion was here:
>>> http://purl.org/TEI/FR/2862151 --we agreed also to allow glossLike
>>> inside space.)
>>>
>>> At the time, although not, I see, in the ticket, I also argued for
>>> glossLike to be allowed inside milestoneLike elements such as tei:lb,
>>> but I guess I didn't convince anybody, perhaps because I didn't have a
>>> compelling use-case to hand.
>>>
>>> I now do.
>>>
>>> We want to be able to express low certainty about a line-break, and
>>> there are, of course, many aspects of the lb element and it's attributes
>>> about which we might be less certain. Wouldn't it be lovely to be able
>>> to do the following:
>>>
>>> <lb n="13"><certainty cert="low" match=".." locus="location"/></lb>
>>>
>>> All perfectly canonical, except that tei:lb can't contain glossLike
>>> elements. Would anyone be offended by this suggestion (or have other
>>> ways of encoding this information that make my proposal redundant)?
>>>
>>> Cheers,
>>>
>>> G
>>>
>>>
>>
>> _______________________________________________
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived
>