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

[Gabriel Bodard]

To follow up: I don't think that any of the comments on TEI-L since I 
asked this significantly change the picture.

Again, we're suggesting a change in the wording of the Guidelines to 
make the context of @match the parent node by default. I can imagine 
this breaking any existing implementations, and (as I said) it wouldn't 
prevent Council from coming up with anything better at the next face to 
face.

Last time I asked the only response was from Peter who had no 
objections. Anyone else want to chip in? (Does anyone think, e.g., that 
we should deprecate @match altogether and recommend the use of XPointer 
schemes in @target?)

Thanks,

Gabby

Gabriel Bodard a écrit :
> 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/