Re: Microcomponents, match and select

My opinion:

There are some components that must take a select expression because 
they contain XPaths that must be evaluated relative to the context node. 
An example is p:string-replace: the replace option must be a select 
expression, because it needs to be evaluated relative to the node whose 
value is being replaced.

In other cases, where the context node is the document node, either an 
expression (select) or a pattern (match) could be used. I strongly 
object to allowing both: that should be our absolute last resort if we 
can't get agreement otherwise.

By definition, every pattern can be turned into an expression by putting 
'//' in front of it (e.g. match="@id" does the same thing as 
select="//@id").

Given that the context node is the root node, most expressions are 
patterns (e.g. select="/company/department" does the same thing as 
match="/company/department"). The exceptions are those that aren't 
location path expressions (i.e. function calls and bracketed 
expressions, in XPath 1.0; a few other things in XPath 2.0). In most 
cases, an equivalent pattern can be created; in all cases, using the 
pattern "node()[count(.|expression) = 1]" will give you the equivalent 
of the expression. (This is assuming that we're not adding to basic 
XPath with a document() function, and thus that all nodes examined are 
in the same document.)

So, in terms of functionality, expressions and patterns are equivalent. 
In most cases, expressions are patterns. And in the general case it's 
easier to turn a pattern into an expression than vice versa.

So I think that this has to be decided on usability. The killer for me 
is that if a user accidentally writes a pattern where an expression is 
expected, they won't get an error, just won't get the behaviour they 
wanted. For example, if they do value="@id" by mistake, they won't know 
that there's a problem until they look at the result, which might be 
several steps down the pipeline and therefore a bit laborious to track down.

Conversely, if they accidentally write an expression where a pattern is 
expected, it will either work fine (because the expression is a pattern) 
or they will get an error. For example, if they do 
value="/company/department" then that's a valid pattern that works in 
the same way as the expression; if they do value="(//p)[1]" then they 
will get an error (probably during pipeline analysis) and mend their ways.

This argues (fairly strongly, I think) for defining options as patterns 
rather than expressions.

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Thursday, 26 April 2007 21:36:29 UTC