[tei-council] Examples for certainty|precision @match

[Martin Holmes]

On 12-11-29 06:41 AM, Gabriel Bodard wrote:
> On 2012-11-29 12:50, James Cummings wrote:
>> On 29/11/12 11:11, Gabriel Bodard wrote:
>>> 1. What is the starting point assumed to be for any @match (in the
>>> absence of @target)? The guidelines say current element, but some
>>> examples in CE seem to assume the element's parent;
>>
>> The guidelines explicitly say the opposite of this surely?  They
>> say things like:
>>
>> "When no target is specified, by default the proposed certainty
>> applies to its parent element, in this case the placeName
>> element. The match attribute discussed below may be used to
>> further vary this behaviour."
>> and
>> "As previously noted, if no value is supplied for target, the
>> context within which the value of match should be evaluated is
>> the parent element of the certainty element itself."
>
> I think we're in violent agreement here, just perhaps my formulation
> wasn't clear. As I interpret it, the guidelines (in the classSpec for
> att.scoping) explicitly specify that (1) any XPath in @match should be
> interpreted as starting from the context of the element bearing this
> attribute (this is what I menat by "starting point" above), and (2) that
> in the absence of @match, the object of the certainty|precision
> statement is the parent of the element bearing this attribute.
>
> As I read it, this means that, as written, the following would be
> correct for a certainty statement qualifying a gap element:
>
> <gap><certainty/></gap>
>
> But if you wanted to specify an attribute on gap, then you would need to
> say:
>
> <gap @reason="lost"><certainty match="../@reason"/></gap>
>
> Do I take it that the two people who have voted for b. so far are saying
> they would prefer the first of those to remain correct, but the second
> to become <certainty match="@reason"/> (as *some of* the examples in the
> GL currently offer)?

Yes, that was what I thought I was voting for.

>> It is only on the reference page for att.scoping that it says
>> that @match:
>>
>> "supplies an arbitrary XPath expression identifying a set of
>> nodes, selected within the context identified by the target
>> attribute if this is supplied, or within the context of the
>> element bearing this attribute if it is not."

That looks good to me, assuming the example in att.scoping is also 
changed accordingly -- so:

<gap reason="cancelled">
  <certainty match="parent::tei:gap/@reason" locus="value" cert="low"/>
</gap>

should presumably be:

<gap reason="cancelled">
  <certainty match="@reason" locus="value" cert="low"/>
</gap>

Cheers,
Martin

>> I would contend that this should just be changed to "or within
>> the context of the parent of the element bearing this attribute
>> if it is not." (or something even clearer!)
>>
>>> 2. What is the assumed context of any certainty|precision element in the
>>> absence of @match (and @target)? The guidelines say current element's
>>> parent, which I feel is slightly unintuitive alongside the official
>>> answer to question 1.
>>
>> I think to say one of these is 'official' and the other isn't is
>> a bit misleading. ;-)
>>
>>> There are then 4 possible solutions to this:
>>
>> I would vote for b.
>>
>> -James
>>
>>
>>>      a. context is always current element, so most @match attributes will
>>> begin "../", but other possibilities such as match="preceding::lb[1]"
>>> are possible. This may be the most strictly rational solution, although
>>> not the most popular, as far as conversation so far indicates. (Plus,
>>> and more importantly, I bet no one actually uses xsl:evaluate to
>>> interpret the content of @match as XPath...)
>>>
>>>      b. context is always parent of current element, so @match can often be
>>> omitted, and most examples in the Guidelines showing values such as
>>> match="@reason" are correct. This is also nice and consistent, if
>>> slightly more limiting (but in a good way: a certainty element can no
>>> longer refer to itself), and also convenient for anyone who doesn't want
>>> to have to evaluate document-source XPath on the fly, but just embed
>>> certainty|precision inside the qualified element and treat it as an
>>> "enhanced attribute".
>>>
>>>      c. context is current if there is content in @match (and no @target),
>>> parent if there is not: status quo; examples in guidelines need fixing.
>>> (Slightly unintuitive?)
>>>
>>> [d. context is parent if there is content in @match (and no @target),
>>> current if not: clearly nonsense.]
>>>
>>> There are arguments for and against all of a, b and c. In my opinion b
>>> is the strongest, for the reasons articulated above (and argued by James
>>> yesterday), but there may be some value to c, the status quo.
>>>
>>> Does this express the options clearly, do you think?
>>
>>
>>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)