Support EXSLT (XSLT extensions). EXSLT provide additional functions to XSLT. A library exists in the system (since Panther) called libexslt.dylib. It would be easy to link webkit against this library and then use it. For this purpose I think the function exsltRegisterAll is of interest.

Created attachment 3027 [details] Test case for one function, part of EXSLT. This is a test case for libexslt support. It checks the availability of the date:date function. EXSLT has many other functions but does it make sense to test them individually ? If the date:date function fails, it means that the date module has not been registered or EXSLT is not enabled at all. This is my first test case so it is certainly not perfect ( comments welcome).

Confirming that the test case fails in Safari, succeeds in xsltproc. Firefox 1.5 fails even worse.

Created attachment 5630 [details] proposed fix Just do what the reporter has proposed (without really thinking this through :) ).

Comment on attachment 5630 [details] proposed fix Looks OK. There are other places we might choose to register exslt, however this one is fine.

Patch looks short and sweet, but before landing we should maybe look into the following: - what other browsers support EXSLT? - is EXSLT relatively stable as a spec and implementation (so we won't be creating future possible compat issues)? - is libexslt a high-quality implementation that is reasonably robust? I think we should do some minimum level of due diligence before adding a new technology and a new dependency.

Also: 4) Does registering exslt have an effect on other clients in-process who are also using libxslt? Good or bad?

Comment on attachment 5630 [details] proposed fix Removing this from the commit queue until mjs's & darin's comments are addressed.

Support for exslt:node-set alone would be extremely useful. It's supported in Firefox3 and Opera 9.1, and MSIE has an equivalent extension (in their name space, of course).

Adding support for EXSLT via libexslt would be an *ENORMOUS* win for Safari, closing the final gap in browser support for exsl:node-set() while giving an extensive library of useful and, most importantly, productive functionality to the Safari web developer.

This seems reasonable to me. We will need to include libexslt in the Windows WebKitAuxiliaryLibraries though in order to have it for Windows. We will also need #if ENABLE(EXSLT) and turn it on just for Mac and Windows. (See how XSLT's ifdef/enabling works.)

PLEASE NOTE: In a recent post to XSL-List and EXSLT-DevList regarding the stability of the EXSLT spec, Dr. Michael Kay [http://saxonica.com] >> If it has a problem, it's that it's been too stable... There's quite a lot in there that is a bit tentative and has been in that state for some years and could do with firming up. However, it does distinguish stable specifications from the more tentative proposals. The specs are a bit informal, which means you may get interoperability issues across implementations in corner cases, but you're unlikely to hit serious backwards compatibility issues because it's an informal spec so as a vendor you always have the choice whether to implement any changes or not. The other issue of course is that many of the EXSLT functions become obsolete when you move to XSLT 2.0, so if you put them into a 1.0 implementation now you may be committing yourself to carry them forward into a future 2.0 implementation where they are (in many cases) no longer needed except for backwards compatibility. << In regards to the second paragraph, it would be impossible to know what plans Apple might have for supporting XSLT 2.0, so this is obviously something that would need to be considered from a strategic level more so than a technical level, but my guess is that regardless of this decision, the reality of continuing to provide the libexslt library alongside any future implementation of XSLT 2.0 would be less of a concern, especially if that future XSLT 2.0 support were to come as a direct extension to the libxslt/libexslt library itself.

(In reply to comment #10) > This seems reasonable to me. We will need to include libexslt in the Windows > WebKitAuxiliaryLibraries though in order to have it for Windows. > > We will also need #if ENABLE(EXSLT) and turn it on just for Mac and Windows. > (See how XSLT's ifdef/enabling works.) > That's great news, Dave! Looking forward to actively testing on both Mac and Windows once the support is made available. :)

I just worked up a patch for this before searching and noticing this issue. Considering FF and Opera support at least exsl:node-set(), I agree WebKit should have this too. Programming XSLT 1.0 without this function can be fairly painful. My impression is that the XSLT community considers node-set() a basic necessity. IMO enabling all of exslt available (with exsltRegisterAll()) is the best approach tho. I will try to add a test case.

(In reply to comment #13) > I just worked up a patch for this before searching and noticing this issue. > Considering FF and Opera support at least exsl:node-set(), I agree WebKit > should have this too. You can also get IE 5.x, 6, and 7 to support it using a trick from Julian Reschke (in whom I believe started this thread) that extended from an idea first suggested by David Carlisle. You can find the details and test code @ http://dpcarlisle.blogspot.com/2007/05/exslt-node-set-function.html > Programming XSLT 1.0 without this function can be fairly > painful. My impression is that the XSLT community considers node-set() a basic > necessity. Oh this is for certain! > IMO enabling all of exslt available (with exsltRegisterAll()) is > the best approach tho. I completely agree, especially given the ease of integrating it via using exsltRegisterAll. That said, please see my follow-up comment[1] to Kurt Cagle earlier today regarding what I would personally term as the most important extension beyond exsl:node-set() > Extension Functions. :) [1] http://www.oreillynet.com/xml/blog/2007/06/apple_sees_the_xslt_light_adds.html#comment-879580 > > I will try to add a test case. Thanks for your help and support with this, Todd! >

Someone needs to sign up to do the work here for this to make Safari 3.

Dave, I assume by "someone" you are referring to an internal Apple employee?

(In reply to comment #13) > I will try to add a test case. Something that would help the most are examples of actual Web sites using EXSLT features (as mentioned above, FF and Opera support exsl:node-set(), so I suppose there should be at least a few such sites?)

Here's an example: <http://greenbytes.de/tech/webdav/rfc4287.xml>

(In reply to comment #17) > (In reply to comment #13) > > I will try to add a test case. > > Something that would help the most are examples of actual Web sites using EXSLT > features (as mentioned above, FF and Opera support exsl:node-set(), so I > suppose there should be at least a few such sites?) > While I need to clean up the sample XML data to make more sense (I pulled the data from a yet to be launched site), http://test.atomictalk.org/index.xml and http://test.atomictalk.org/index-node-set.xml will provide two samples: the first doesn't use node-set, the second does. The code is checked into http://atomictalk.googlecode.com/svn/trunk/ What this does: As the XML is parsed, it looks for @@ symbols (e.g. @@name-of-advice-element@@), looks for the advice:name-of-advice-element in the /my:session/my:page/page:config/page:advice/advice:*, and replaces the content of that element inline where it found the @@name-of-advice-element@@. Of course, each advice element can contain the name of another advice element, and can also use conditional logic to determine if content should be replaced, and if so with what. Without using exsl:node-set, this is dynamically evaluated each time the processor comes across an @@element-name@@ code block, so quite obviously this is an expensive way to process the advice elements. Using node-set, the advice elements can be "pre-compiled" so it becomes a simple matter of looking up the element name and replacing the @@element-name@@ with the static string value of the element. That said, I quickly rewrote the tranformation code to accomodate the usage of exsl:node-set() for testing purposes. More work is needed before it will be a good side-by-side comparison of using exsl:node-set() compared to not using it. At the moment it pre-compiles the advice elements but doesn't use that pre-compiled data during the replace operation. It's going to take quite a bit more code rewrite to get that to work properly, so for now this is simply a way to test whether exsl:node-set() is working properly. I'll update this thread when the code has been rewritten in such a way as to be a good side-by-side comparion test case for exsl:node-set().

Created attachment 15386 [details] Test EXSLT support This test, taken with minor modifications from <http://www.biglist.com/lists/xsl-list/archives/200706/msg00280.html>, lists supported EXSLT functions and elements. Opera 9.2 only supports exslt:node-set(), while Firefox 3 alpha has more extensive (but still far from complete) support. It seems that exslt:node-set() is a must have, but the question of bringing in the whole libexslt is not entirely obvious to me. If we do so, it may complicate the task of rewriting our XSLT support to avoid creation of a separate DOM tree. Can we start with only adding node-set() to our own contexts (with xsltRegisterExtFunction())? This would avoid affecting other clients in-process who are also using libxslt.

(In reply to comment #20) > Can we start with only adding node-set() to our own contexts (with > xsltRegisterExtFunction())? This would avoid affecting other clients in- > process who are also using libxslt. The *real* key to all of this, in my own opinion, is providing the -- for all intents and purposes -- mandatory capability provided by the node-set function while at the same time providing consistency across browsers. While the extended functionality of libexslt is nice, it certainly doesn't do a whole lot for the cross-browser developer, and having had *MANY* years of experience with the XSLT communities at large, I can assure that if there is one area of primary encouragement and focus it is that of maintaining consistency, writing portable XSLT when at all possible. And this comes from a world in which the primary XSLT code base has been written to run on the server where control over the environment can be maintained. The point becomes several magnitudes stronger when you consider that there are 4 primary browsers with enough market share to force at very least some effort at providing support for each of them. In this regard, and while I hate to admit it, providing support past that of node-set could very easily be seen as a complete waste of time.

exslt:node-set() is now in.

(In reply to comment #22) > exslt:node-set() is now in. > FYI > http://www.oreillynet.com/xml/blog/2007/07/apple_listens_to_community_add.html

Does Windows have libesxlt support? Did it get added to the auxiliary libs?

(In reply to comment #24) > Does Windows have libesxlt support? Did it get added to the auxiliary libs? > Yes > http://www.oreillynet.com/xml/blog/2007/07/apple_listens_to_community_add.html (updatd w/ screenshots of both Safari+Mac and Safari+Windows) :D

(In reply to comment #24) > Does Windows have libesxlt support? Did it get added to the auxiliary libs? > A bit of strangeness to report, via http://www.oreillynet.com/xml/blog/2007/07/apple_listens_to_community_add.html#comment-947612 <blockquote>Just curious, how did you get the windows version working? In looking at your screenshot, you ran ...\WebKit-r24096\run_nightly_webkit.cmd which is identical to what I run (except for the full directory path) but I am getting a blank page. Thanks! Bruce</blockquote> Any ideas?

(In reply to comment #26) > Any ideas? Apparently not yet... Please file a new bug if this is a reproducible issue, as it may turn out to be unrelated to EXSLT. Let's keep this bug to track (possible) implementation of other EXSLT features.

In reply to 27, I just installed windows nightly 24238 and it is now working fine. I might have been using an old nightly - sorry.

When u have exslt support, you can test using my lo tech exslt coverage xslt, explained here http://jimfuller.blogspot.com/2007/09/testing-exslt-support.html or you can just point your browser to here http://www.webcomposite.com/func-avail.xsl cheers, Jim Fuller

(In reply to comment #29) > When u have exslt support, you can test using my lo tech exslt coverage xslt, explained here > > http://jimfuller.blogspot.com/2007/09/testing-exslt-support.html > > or you can just point your browser to here > > http://www.webcomposite.com/func-avail.xsl Bug 15231

I have a need for the EXSLT strings:tokenize() function, I've patched XSLTExtensions.cpp for my own purposes, but I'd like to see it in WebKit. Since XSLT 2.0 is nowhere in sight, EXSLT is the only hope! I don't think it makes sense to add functions piecemeal; after nearly 5 years is there still anything preventing libexslt being included in the build and exsltRegisterAll() being called from registerXSLTExtensions() in XSLTExtensions.cpp?

Nothing changed, adding full support is still blocked on having good answers to the questions in comments 5 and 6.

Let's try to answer these then: Q) What other browsers support EXSLT? A) Firefox 3.0 seems to support most of EXSLT: https://developer.mozilla.org/En/EXSLT, obviously Safari and Chrome are limited by Webkit support (or lack of). IE and Opera don't seem to support anything other than node-set. Q) Is EXSLT relatively stable as a spec and implementation? A) It seems so, the most recent exslt update I can find on exslt.org is Oct 14th 2003! Q) Is libexslt a high-quality implementation that is reasonably robust? A) Hard to answer, but it seems so for the set of functions I've used (via Todd's XSLMate plugin for TextMate). Q) Does registering exslt have an effect on other clients in-process who are also using libxslt? A) Again, hard to answer, but since EXSLT functions exist in their own set of namespaces, probably not. For the last two questions, it seems that only going ahead with a complete EXSLT and then testing it will determine the answers.

I'd like to add my support for supporting more of EXSLT (or to implement XSLT 2.0 :-). Matching FF's functionality probably would be cool, as it would allow many more things in almost all UAs (note that for IE an XSLT can always fallback to MS-specific extension functions, as demonstrated for node-set many times). FF does *not* implement exslt:date, which is a shame, though.

> FF does *not* implement exslt:date, which is a shame, though. Support for exslt:date-time (and just that) was just added to Mozilla trunk (https://bugzilla.mozilla.org/show_bug.cgi?id=603159)

(In reply to comment #35) > > FF does *not* implement exslt:date, which is a shame, though. > > Support for exslt:date-time (and just that) was just added to Mozilla trunk (https://bugzilla.mozilla.org/show_bug.cgi?id=603159) ...and is present in Firefox 6 beta as of now (target release date August 2011)

(In reply to comment #36) > (In reply to comment #35) > > > FF does *not* implement exslt:date, which is a shame, though. > > > > Support for exslt:date-time (and just that) was just added to Mozilla trunk (https://bugzilla.mozilla.org/show_bug.cgi?id=603159) > > ...and is present in Firefox 6 beta as of now (target release date August 2011) ...and released. See also <http://greenbytes.de/tech/tc/xslt/#ft-exslt-date-time>

Is there any update on this? Please note that the key questions and concerns from comment #5 and #6 were addressed in comment #33. This is one of the items that IE is seems to be superior to Chrome: in IE 6+ one can use scripts to implement most of the EXSLT functionality.

Is this something that's still relevant in 2022?

Yes.