RE: [xsl] Proposed syntax for namespace binding in XPath

["Michael Kay" <mike@xxxxxxxxxxxx>]

> The basic idea is simple:
> 
> ("your special syntax") and rest/of/expr ("your special 
> syntax")[2] | rest/of/expr
> 
> For example, with namespace binding syntax, this could become:
> 
> ("xmlns(xmlns=http://mynamespace 
> xmlns:you=http://yournamespace)")[2] | path/with/you:your-namespace

In interesting idea. But I can think of some further drawbacks:

1. Not easy to recognize when the syntax is in use (applies to human readers
as well as XPath processors)

2. Impossible to generate error messages: difficult to diagnose mistakes

3. Is there really such a thing as a no-op? Your examples aren't: the first
example changes EXP to boolean(EXP) and the second causes an error if the
expression delivers atomic values rather than nodes.

An adaptation that eliminates these disadvantages would be:

saxon:namespaces("xmlns=abc.uri xmlns:p=pqr.uri"), EXPR

(I think that E1,E2 where E1 is an empty sequence really IS a no-op)

But it feels a bit like an abuse.

Michael Kay
http://www.saxonica.com/


> 
> The most obvious drawbacks are:
> 
>   1. The need of having a no-op that costs some processing 
> power on processor that do not understand the special syntax
>   2. Processors that are currently optimized to statically 
> remove these no-ops will have to make an exception for these cases
>   3. Using a string containing the syntax is not quite pretty 
> (but that argument can be used with comments as well)
>   4. Processors have to understand certain no-ops and 
> recognize the syntax in it (but that should not be that hard 
> if you formalize the syntax)
> 
> The most obvious positive points I can think of are:
> 
>   1. No (major) change in parser engines, as it is part of 
> the tokenized expression already
>   2. Use of existing syntax instead inventing new syntax
>   3. No violation of current XPath specification
>   4. Forward compatible. I.e., the "special comment" might be 
> used once for a new construct, or some other vendor might 
> make its own extensions; by using a sequence of one string 
> however, will remain future-spec proof.
>   5. Using normal XPath escaping of strings, you can easily 
> provide any value for the content (or syntax) of the 
> special-syntax string.
>   6. Since it is part of the XPath, the user is free to 
> choose to create the string dynamically.
> 
> The hardest challenge in this approach, I believe, is clearly 
> defining the rules (and positions in the XPath) where this 
> "featured no-op" may be used. I understood that one of the 
> thoughts was to only use it on the start of the expression, 
> which may greatly simplify this approach.
> 
> Cheers,
> -- Abel Braaksma
>    http://abel.metacarpus.com