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

[Kevin Hawkins]

Actually, I believe the base of a relative URI in @target is calculated 
in the following order:

1) The value of @xml:base on the element.
2) The value of @xml:base on the parent element.
3) The value of @xml:base on the grandparent element.
4) etc.
5) / (root)

--Kevin

On 11/28/2012 11:06 AM, Gabriel Bodard wrote:
> I thought the base of an xpointer in @target was deemed to be root,
> *not* any relation to the current node, hence the need for @match in the
> first place?
>
> On 2012-11-28 16:04, Martin Holmes wrote:
>> I see the logic there.
>>
>> If @target is used instead, with an xpath pointer, would the context
>> node for that also be considered to be the parent node? If so, wouldn't
>> that make the user of pointers in att.scoping/@target different from
>> @target defined in e.g. att.pointing?
>>
>> Cheers,
>> Martin
>>
>> On 12-11-28 07:30 AM, James Cummings wrote:
>>>
>>> Whereas my intuition is telling me the exact opposite. ;-)
>>>
>>> If we have:
>>>
>>> <name type="place">Foo<certainty match="$" locus="value"
>>> degree="0.5"/></name>
>>>
>>> I think the certainty can't and *shouldn't* be able to refer to
>>> itself, that is what a nested certainty is for, therefore the
>>> default @target is an assumed parent::node(). So in this case $
>>> should be @type not ../@type.
>>>
>>> As Gabby pointed out the flaw in this reasoning of mine is where
>>> we want to be uncertain or imprecise about milestone elements
>>> which don't have certainty in them (lb for example).  That is why
>>> I'm with him in thinking they should have this content (and I
>>> think should have<desc>  as well given recent discussion on TEI-L).
>>>
>>> -James
>>>
>>> On 28/11/12 13:49, Martin Holmes wrote:
>>>> This is a tough one. My instinct is that we should go with what seems to
>>>> be intuitive, and what's most intuitive to me is that if you specify
>>>> nothing, the default is the current context. In other words, the default
>>>> value of @match should be ".", and that if you want to point to a parent
>>>> element, you have to use "..". That means the examples should be
>>>> rewritten to:
>>>>
>>>> <certainty match="../@who" locus="value" degree="0.5"/>
>>>>
>>>> etc. And in realistic usage, the @match attribute would be required, to
>>>> prevent the<certainty>  attribute from expressing uncertainty about itself.
>>>>
>>>> This would also make @match in line with @target; if @target contained a
>>>> TEI Pointer of some kind, that would be evaluated relative to the
>>>> current context<certainty>, wouldn't it?
>>>>
>>>> My head hurts when I think about this, though.<certainty>  can contain
>>>> <certainty>, meaning that you could have a child<certainty>  expressing
>>>> doubt about the value of the parent<certainty>'s @match attribute,
>>>> while the parent<certainty>  could express doubt about the child
>>>> <certainty>'s @target. Gawd.
>>>>
>>>> Cheers,
>>>> Martin
>>>>
>>>> On 12-11-26 04:41 AM, Gabriel Bodard wrote:
>>>>> After fixing the problem with certLike having been inadvertently removed
>>>>> from the content model of<space>, I was about to add an example or two
>>>>> to the usage of<certainty>  and/or<precision>, when I noticed an
>>>>> apparent inconsistency (or at least potential confusion) in the
>>>>> guidelines description of the @match attribute.
>>>>>
>>>>> At
>>>>> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.scoping.html>,
>>>>> @match is defined:
>>>>> "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."
>>>>>
>>>>> I take this to mean that in the absence of @target, if I want to point
>>>>> to a<gap>  element from a<certainty>  inside it, I should write:
>>>>>
>>>>> <gap><certainty match=".."/></gap>
>>>>>
>>>>> (The example under match indeed gives match="parent::tei:gap/@reason",
>>>>> which I take to be consistent with my usage.)
>>>>>
>>>>> A note further down adds:
>>>>> "If neither attribute (sc. @target, @match) is present, the expression
>>>>> of certainty applies to the context of the certainty element itself,
>>>>> i.e. its parent element." (For starters, this should say "certainty,
>>>>> precision etc.".)
>>>>>
>>>>> But I take this to mean that an element<precision/>  should be
>>>>> understood to have a default value of match=".." (rather than match="."
>>>>> which might be more intuitive). This is not inconsistent, but perhaps
>>>>> slightly confusing. (At the very least we should offer more examples here.)
>>>>>
>>>>> In the examples at
>>>>> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CE.html#index-body.1_div.21_div.1_div.2_div.4>
>>>>> (yuk!) however, we uniformly see values such as:
>>>>>
>>>>> <certainty match="@who" locus="value" degree="0.5"/>
>>>>> <certainty match="@resp" locus="value" degree="0.2"/>
>>>>> etc.
>>>>>
>>>>> Since the certainty element in these cases has neither who nor resp,
>>>>> this usage seems to imply that the starting point for the XPath in
>>>>> @match is the parent of the [certainty|precision] element that bears the
>>>>> @match attribute.
>>>>>
>>>>> On the one hand, it is probably simplest to say that the examples in CE
>>>>> are wrong and we should just fix them by prefixing all of these @ with
>>>>> ../ (which is how I've been using this attribute).
>>>>>
>>>>> On the other, however, if the starting point of the XPath were the
>>>>> parent element rather than the [certainty|precision] element itself,
>>>>> then it becomes less defensible to have some transcriptional elements
>>>>> that cannot take certainty or precision as children, as I argued at the
>>>>> last F2F. So I don't mind which way we go on this one. ;-)
>>>>>
>>>>> Any thoughts?
>>>>>
>>>>> G
>>>>>
>>>>
>>>
>>>
>>
>