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

Thu Nov 29 06:11:11 EST 2012

That rings a bell. :-) So in the absence of @xml:base, the starting 
point for any xpointer in @target is root. (Which was an aside anyway.)

There are two questions re the starting point for xpath in @match:

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;

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.

There are then 4 possible solutions to this:

  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?

G

On 2012-11-28 17:16, Kevin Hawkins wrote:
> 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
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>

-- 
Dr Gabriel BODARD
Researcher in Digital Epigraphy

Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

T: +44 (0)20 7848 1388
F: +44 (0)20 7848 2980
E: gabriel.bodard at kcl.ac.uk

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/