From: TOM (ptittom@free.fr)
Date: Thu Oct 26 2000 - 19:42:35 EDT
On 26/10/2000 14:57:06 Daniel Veillard wrote:
> > - doesn't seem there is a namespace support for functions
> > (last() is equivalent to foo:last() and bar:last()), it'll be
> > necessary for proprietary XPath extension functions.
>
> humm, do we really need namespace in that case, IMHO it should
> just be string comparisons.
Give a look at the XSLT 1.0 Recommandation, section 14.2:
14.2 Extension Functions
If a [409]FunctionName in a [410]FunctionCall expression is
not an [411]NCName (i.e. if it contains a colon), then it is
treated as a call to an extension function. The
[412]FunctionName is expanded to a name using the namespace
declarations from the evaluation context.
[...]
Function: boolean function-available(string)
The argument must evaluate to a string that is a [420]QName.
The [421]QName is expanded into an [422]expanded-name using
the namespace declarations in scope for the expression. The
[423]function-available function returns true if and only if
the expanded-name is the name of a function in the function
library. If the expanded-name has a non-null namespace URI,
then it refers to an extension function; otherwise, it
refers to a function defined by XPath or XSLT.
It's only for XSLT, not more generaly XPath.
The lookup should at least be done with the complete QName and not only
its local part. I guess this will be sufficient.
And last() won't be equivalent to foo:last() since last() is the XPath
function but not foo:last() (an extension function).
Not modified:
I notice xmlXPathEvalVariableReference() uses xmlXPathParseName(), but
Names and QNames aren't identical: a Name can begin with and contain more
than one colon.
Since no validation is done at function registering, we may have a
function which hasn't a valid name and then allow calls of such functions.
This shouldn't happen but it can.
If we don't fix this, the error message isn't XPATH_VARIABLE_REF_ERROR
(as it should be) but XPATH_UNDEF_VARIABLE_ERROR.
If we change something, we must change both
xmlXPathEvalVariableReference() and xmlXPathEvalFunctionCall().
There are at least two way to handle that:
1. parse a QName then strcat the Prefix and the LocalPart and finally
look up for the function/variable. This is costly in memory.
2. parse a Name then verify it's a QName (the first character isn't a
colon and there isn't more than one colon in it) and do the look up. This
is a bit dirty.
> > I didn't know what to change (it would be easier to modify
> > xmlXPathStringEvalNumber()) so I did nothing.
>
> yes that's probably the right place to handle this.
done.
By the way, where can I find the IEEE 754 ?
> > - I don't understand why xmlXPathEval() (actually
> > xmlXPathEvalExpr() called within xmlXPathEval()) must return a
> > node-set. [...]
>
> yes that must be fixed.
done.
The patch applies well and compiles on a libxml2-message-2.2.6 with my
precedent (fixed) patch.
It also fixes a bug in the sum() function (xmlXPathSumFunction()) which
returned a node-set when the node-set argument contained only one node.
Other functions still need debugging (I still have segfaults from time
to time).
I remove the double registry of xmlXPathNormalizeFunction() (and fix the
help comment, but don't rename it ;o).
(if anyone has time to tell me how to organize myself and use the tools
[RCS, diff and patch] in a good way, not to give more work than necessary
to Daniel [and others], he's invited to contact me in private ;o)
Tom
---- Message from the list xml@rpmfind.net Archived at : http://xmlsoft.org/messages/ to unsubscribe: echo "unsubscribe xml" | mail majordomo@rpmfind.net
This archive was generated by hypermail 2b29 : Thu Oct 26 2000 - 20:43:31 EDT