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
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--