2010/3/11 ustbcoder <ustbco...@gmail.com> > XPath: /doc/name[ends-with(@first,'d')] > --------------------------------[1]
> expresion: str:endswith(/doc/na...@first],'d') > -----------------------------[2] > > Let's compare [1] and [2], we can find that [1] is the normal XPath expresion > in XPath 2.0,but [2] is not. > I think this confuses them. The way, [1] above would work with a native (i.e, built-in) XPath/XSLT functions. Any extension functions supported by Xalan, or if you want to use the EXSLT functions (as you've cited above), then any extension function calls must belong to a specific namespace (as the prefix, str:.. as you've cited). I think, it's the usage of another namespace for extension functions, that's probably confusing you. Whether we like it or not, prefixing the extension function calls with a namespace prefix (and declaring the corresponding namespace URIs), is a correct way (and, XML Namespace compliant) to call (and design by a XSLT/XPath engine) extension functions. An another namespace, for extension functions helps us to distinguish, that this is an extension function, and not a built in language function. > So, this is why i want to implements XPath 2.0 functions for Xalan. When I have to work with Xalan, and I'm in need of some function, that's not supported by the standard language, I try to use an existing extension function, provided by Xalan, or can try to create my own function with Java. > I want to implement XSLT 2.0 datamodel too, and then implement all the XSLT > 2.0 > recommendation for Xalan. Implementing XSLT 2.0 spec, for Xalan would completely change the Xalan product. It would turn from a XSLT 1.0 processor to a XSLT 2.0 processor :) This is not a trivial task, and implementing a language spec in entirety, is certainly challenging. I wish you good luck, in your endeavors. -- Regards, Mukul Gandhi
