User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:184.108.40.206) Gecko/20070723 Iceweasel/220.127.116.11 (Debian-18.104.22.168-1)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:22.214.171.124) Gecko/20070723 Iceweasel/126.96.36.199 (Debian-188.8.131.52-1)
As Xpath 2.0 and Xslt 2.0 is a w3c recommendation, it would be a good idea to implement it into the engine.
(In reply to comment #0)
> As Xpath 2.0 and Xslt 2.0 is a w3c recommendation, it would be a good idea to
> implement it into the engine.
One doesn't follow from the other, and it is very unlikely that we will implement XSLT 2.0 or even XPath 2.0. Are there any specific features you are looking for?
(In reply to comment #1)
> (In reply to comment #0)
> > As Xpath 2.0 and Xslt 2.0 is a w3c recommendation, it would be a good idea to
> > implement it into the engine.
> One doesn't follow from the other, and it is very unlikely that we will
> implement XSLT 2.0 or even XPath 2.0. Are there any specific features you are
> looking for?
Mainly the paty of the specification for strings, as xpath 1.0 doesn't handle escaping characters (" and ')
would it be possible to enable xpath to escape quotes?
implementing xpath2 functions ( http://www.w3.org/TR/xpath-functions/ ) could be very useful for XUL templates based on an XML datasource, since these kind of templates use XPath to get nodes.
I agree with #4, xsl:function extends the functionality of xslt very well.
Also it's a W3C standard, there's no harm to implement it anyway (no compatibility issues if the version attribute of xsl:stylesheet is correctly assigned).
XPath is an important declarative language to implement Node selection in the DOM.
Building on the existing support for Xpath, tools such as XPather permit rich exploration and selection of DOM content without coding endless iteration and expansion routines.
However, XPath 1.0 has a number of limitations experienced by adopters which were addressed by additional constructs in XPath 2.0.
This means that certain sets of nodes and transformations of node content are simply not achievable in XPath 1.0 and todays Firefox without migrating to XPath 2.0.
XSLT 2.0 is much more powerful than XSLT 1.0.
There are several major improvements to the language, this is not just some tiny features, yet they blend in so naturally that you wonder why they are not in 1.0 to begin with.
- Remove RTF results in favor of plain node-sets (this one feels almost like a bug fix).
- User defined functions as mentioned in #4.
- Multiple document outputs.
- Regular expressions and parsing functions (how are you supposed to manipulate text nodes without these?)
Some of this features are more or less supported on EXSLT. I don't understand why it's ok to give support to an extension but not to a standard that removes the need for the extension itself.
Even more so if you consider the extension implementation is incomplete.