In message <4ec2900f0906081750s6ff505fbp2bf5d1788c1eba55@mail.gmail.com> Conal
Tuohy <conal.tuohy@gmail.com> writes:
> Some thoughts about the examples:
> 
> ex 1:
> 
> <egXML xmlns="http://www.tei-c.org/ns/Examples">
> <certainty pattern="@resp" locus="value" degree="0.2"/>
> </egXML>
> This encoding indicates that there is only a 0.2 certainty that any
> value for the <att>resp</att> attribute is correct, wherever it
> appears in the document.</p>
> 
> I think we need to be clear about what the context is in which the pattern
> is to be evaluated. In the first example there's no @path so the context is
> undefined (I take it?), 

No. If there's no @target (there;s never any @path!), the implied context is the
document root.
...
> 
> In general, I agree with the comments that the technique, while nice to
> have, is well overpowered for Gabriel's use case. Syntactically it's
> slightly easier than xpointer, but in terms of expressive power it's much
> the same isn't it? On the other hand, being able to qualify all the
> assertions with a particular @resp sounds like a useful trick, and I could
> imagine wanting to qualify all the <corr> elements inside a particular <div>
> or some such, so it's not outrageous.
> 

I think I now understand a lot better how the @pattern proposal relates to our
existing use of @target, which (being a URI) does permit inclusion of an xpath.
We could choose to use either @pattern or @target only, since they have almost
entirely overlapping expressivity, but this would close the door to a large
number of syntactic sumplifications. Without @target you couldn't say
@target="#foo"; without @pattern you couldn't say just '@foo' to acccess an
attribute value. So I think the problems are really just of
description/documentation.  I also think that this new facility  makes the
proposals in the Certainty module really useful -- enabling us to deliver on
some vague hand waving at various points of the Guidelines in a practical and
useful way. Consider, for example, the ability to include a set of <certainty/>
elements in your <encodingDesc> to specify that e.g. the <name> elements were
all added automatically and are therefore less reliable than the <persName>
elements which were manually added by an expert.


> Finally, regarding namespaces, I think it'd be enough to assert in the
> guidelines that the namespace bindings to use in the evaluation of the
> @pattern expression should just be the namespace bindings in effect at that
> location in the document (i.e. on that <certainty> element).
> 

Yes, that's my opinion too. The namespace prefixes available in your @pattern
value are those available in the parent document. (This is another example of
the syntactic sugaring provided by this attribiute; in an xpaths you must
specify namespaces fully.)


p.s. Hello Con!


> Con