[tei-council] [Fwd: Re: [TEI-L] certainty, @match, and XPaths redux]

[Gabriel Bodard]

This seems like a reasonable request from Hugh. (Wendell's suggestion to 
use @select would be a good one, except that an @select is already 
available on <certainty/> with completely different semantics.) Is there 
any reason why we wouldn't put this change through for the upcoming 
release, on the understanding that it doesn't prejudice further 
discussions and decisions by Council? (NB, it's only a GL change, not a 
schema one.)

G

-------- Message original --------
Sujet : Re: [TEI-L] certainty, @match, and XPaths redux
Date : Mon, 19 Oct 2009 20:26:58 +0100
De : Hugh Cayless <hcayless at EMAIL.UNC.EDU>
Répondre à : Hugh Cayless <hcayless at EMAIL.UNC.EDU>
Pour : TEI-L at listserv.brown.edu <TEI-L at listserv.brown.edu>

Comments inline below...

Hugh

On Oct 19, 2009, at 11:27 AM, Wendell Piez wrote:

> I'm sorry to flog the horse, and certainly hope this is my last post  
> on this topic. But for the record I'd like to offer my own summary  
> of what's at issue. Readers who don't care are welcome to pass on,  
> or skip to the bottom. :-)
>
> Hugh's paraphrase of my objection isn't entirely right. There is no  
> such thing as an "absolute pattern" per se, in XSLT; and while a  
> @match must be a pattern, patterns do not have to be "absolute  
> paths". Patterns don't even have to be paths at all, though most (in  
> practice, almost all) take the form of path expressions. What  
> patterns don't do is select nodes. They "specify a set of conditions  
> on a node", as the spec has it -- some nodes conform to a given  
> pattern (the conditions specified are true) -- they "match" -- and  
> others don't; that's all. The term "match" has a very specific  
> meaning, which is distinct from the "selection" of nodes by a  
> stylesheet that constitutes its traversal: and this distinction is  
> important to the way XSLT works. In the abstract, whether a given  
> node matches a given pattern has nothing to do with selection, or  
> whether the node is ever selected.

Sorry for the careless wording.  I should have just said "match
pattern" vs. "select pattern".  I'm not sure where "absolute" came
from.  I've probably been doing too much reading about URIs recently.
>
> (To students of XSLT who know something about Taoist philosophy I  
> sometimes offer that @match is the Yin to the Yang of @select. Make  
> of that what you will. :-)

nice.
>
> Yet as I tried to take pains to explain, my quarrel isn't with the  
> semantics of TEI certainty/@match as given; it's with its name, most  
> especially in combination with the explicit statement in the  
> Guidelines that its semantics are borrowed from XSLT, which they  
> aren't. (The Guidelines say the attribute "supplies an XSLT 2.0  
> pattern", and then goes on to misrepresent how patterns are  
> evaluated. Have I stressed that "pattern" is a technical term in  
> XSLT with a precise meaning?)
>
> This is especially confusing since the functional requirements of  
> certainty/@match might have been, but apparently are not, provided  
> by an XSLT match pattern. In this case, in order to address the full  
> requirements as stated by James, a scoping mechanism (such as in  
> xsl:number/@from) would also be needed -- since match patterns, by  
> themselves, have no scope.
>
> As given, however, the certainty/@match semantics are, in fact, more  
> or less exactly the semantics of XSLT's @select attribute, which  
> operates relative to a context node (instead of within the scope of  
> a document or document fragment). This is the main reason I  
> suggested @select as an alternative name.
>
> If this doesn't work due to the name clash with @select elsewhere,  
> there are other possibilities, including a mild semantic overloading  
> of @target, which is feasible since web-style ID references and  
> XPath are syntactically disjunct (XPath expressions never start with  
> '#'). In fact, this is my own personal preference so far. In  
> addition, a @from or @context element could be used along with  
> @target to qualify the selection, but strictly speaking that  
> wouldn't be necessary.
>
> The solution Hugh proposes, to keep the name and document the  
> difference from XSLT, would alleviate the problem but not (I feel)  
> remedy it. Warning XSLT users and learners to be on their guard  
> ("TEI certainty/@match is not really like XSLT template/@match or  
> key/@match") is at least a help, and this need not be embarrassing  
> to TEI. Yet the best would clearly be to avoid the confusing name  
> altogether.

I think you're right on all counts, but also that the damage is done.
Fixing it thoroughly would mean enough surgery on the Guidelines to
warrant a good deal of extra discussion on the part of the council.  I
certainly wouldn't object to that, but our situation in IDP/EpiDoc is
that we have a need to point from certainty elements to the elements
they govern without using xml:id right now, and certainty/@match will
do that with the one small tweak we've proposed.

A more thorough and better fix (and one that takes into account Syd's
point about xml:base) should certainly be considered, but one change
in wording will fix our current problem now, leaving plenty of time
for considering better solutions (like deprecating @match and
replacing it with something else).
>
> The current state of affairs is kind of like an XML document that  
> uses the TEI namespace and TEI names, but whose tagging varies from  
> the TEI Guidelines in subtle but important ways, without saying so.
>
> Cheers,
> Wendell

-- 
Dr Gabriel BODARD
(Epigrapher & Digital Classicist)

Centre for Computing in the Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL
Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

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