> I was looking at the argument lists to the various functions that take
> node-sets in org.jaxen.function, and they don't apear to be consistent.
> Some of these functions take an Object as an argument (count, sum).
> Others take a list and a navigator (name, namespace-uri, local-name).
> Others take a Context (position). It might be nice if these could be
> made consistent.
They all implement call(Context, List) consistently.
The evaluate(...) method tends to match the requirements of the
actual XPath function signature, for the most part.
evaluate(...) isn't consistent across all functions, because the
actual parameter list isn't consistent across all of the core
XPath functions.
I'd say they are different because they need to be. Am I misunderstanding
your statement?
> Is there any standard Jaxen representation of an XPath node-set? Would
> it be helpful to add such a class?
java.util.List
We should document that, I guess. Didn't feel the need to create a NodeSet
object for 2 reasons:
1) List is sufficient
2) It'd be counter-intuitive, since we do maintain order, and
by definition, 'sets' don't.
> The isNaN() methods in NumberFunction duplicate the similar methods in
> java.lang.Double. I'd just delete them.
Hokie dokie. Will take a look.
> The document function is not a standard partof XPath. It should probably
> be moved to the function.ext package, or perhaps a new function.xslt package
> if you're trying to mirror the XSLT document function.
Agreeded. I was hoping all extended functions would be in .ext, but
I guess some didn't make it.
-bob
_______________________________________________
Jaxen-interest mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jaxen-interest
