Subject: RE: [xsl] Proposed syntax for namespace binding in XPath From: "Michael Kay" <mike@xxxxxxxxxxxx> Date: Wed, 4 Apr 2007 20:49:09 +0100 |
> 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Proposed syntax for names, Abel Braaksma | Thread | Re: [xsl] Proposed syntax for names, David Carlisle |
RE: [xsl] Image extension functions, Ryan Lubben | Date | RE: [xsl] Image extension functions, Mauritz Jeanson |
Month |