Re: Microcomponents, match and select

+10

On 4/26/07, Jeni Tennison <jeni@jenitennison.com> wrote:
>
> 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
>
>


-- 
Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 8 72 475787
Fax : +33 1 4356 1746
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 €

Received on Thursday, 26 April 2007 21:40:52 UTC