Bug 4079 - Support EXSLT with libexslt
: Support EXSLT with libexslt
Status: NEW
: WebKit
XML
: 420+
: Macintosh Mac OS X 10.4
: P2 Enhancement
Assigned To:
:
:
: 14525
:
  Show dependency treegraph
 
Reported: 2005-07-20 00:40 PST by
Modified: 2013-08-28 07:14 PST (History)


Attachments
Test case for one function, part of EXSLT. (2.58 KB, application/octet-stream)
2005-07-20 00:53 PST, Romain Brestac
romain.brestac: review-
Details
proposed fix (7.80 KB, patch)
2006-01-12 14:17 PST, Alexey Proskuryakov
no flags Review Patch | Details | Formatted Diff | Diff
Test EXSLT support (2.18 KB, application/zip)
2007-07-04 11:44 PST, Alexey Proskuryakov
no flags Details


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2005-07-20 00:40:33 PST
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.
------- Comment #1 From 2005-07-20 00:53:49 PST -------
Created an attachment (id=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).
------- Comment #2 From 2006-01-03 15:38:08 PST -------
Confirming that the test case fails in Safari, succeeds in xsltproc. Firefox 1.5 fails even worse.
------- Comment #3 From 2006-01-12 14:17:13 PST -------
Created an attachment (id=5630) [details]
proposed fix

Just do what the reporter has proposed (without really thinking this through :)
).
------- Comment #4 From 2006-01-12 14:25:44 PST -------
(From update of attachment 5630 [details])
Looks OK.  There are other places we might choose to register exslt, however
this one is fine.
------- Comment #5 From 2006-01-12 21:42:41 PST -------
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.
------- Comment #6 From 2006-01-13 03:27:03 PST -------
Also:

    4) Does registering exslt have an effect on other clients in-process who are also using libxslt? Good or 
bad?
------- Comment #7 From 2006-01-15 00:24:53 PST -------
(From update of attachment 5630 [details])
Removing this from the commit queue until mjs's & darin's comments are
addressed.
------- Comment #8 From 2007-01-06 04:21:07 PST -------
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).
------- Comment #9 From 2007-06-21 02:26:30 PST -------
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.
------- Comment #10 From 2007-06-21 03:16:22 PST -------
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.)
------- Comment #11 From 2007-06-21 04:15:23 PST -------
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.
------- Comment #12 From 2007-06-21 04:16:32 PST -------
(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. :)
------- Comment #13 From 2007-06-26 19:32:08 PST -------
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.
------- Comment #14 From 2007-06-27 02:22:45 PST -------
(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!
> 
------- Comment #15 From 2007-06-28 22:04:01 PST -------
Someone needs to sign up to do the work here for this to make Safari 3.
------- Comment #16 From 2007-06-29 07:14:29 PST -------
Dave,

I assume by "someone" you are referring to an internal Apple employee?
------- Comment #17 From 2007-06-29 13:22:34 PST -------
(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?)
------- Comment #18 From 2007-06-29 13:40:48 PST -------
Here's an example:

<http://greenbytes.de/tech/webdav/rfc4287.xml>
------- Comment #19 From 2007-07-01 12:31:42 PST -------
(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().
------- Comment #20 From 2007-07-04 11:44:31 PST -------
Created an attachment (id=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.
------- Comment #21 From 2007-07-04 12:02:55 PST -------
(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.
------- Comment #22 From 2007-07-07 03:08:04 PST -------
exslt:node-set() is now in.
------- Comment #23 From 2007-07-07 10:53:16 PST -------
(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
------- Comment #24 From 2007-07-08 21:35:06 PST -------
Does Windows have libesxlt support?  Did it get added to the auxiliary libs?
------- Comment #25 From 2007-07-08 22:31:51 PST -------
(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
------- Comment #26 From 2007-07-10 10:07:04 PST -------
(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?
------- Comment #27 From 2007-07-11 06:01:14 PST -------
(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.
------- Comment #28 From 2007-07-12 09:50:52 PST -------
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.
------- Comment #29 From 2007-09-17 07:57:12 PST -------
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
------- Comment #30 From 2007-09-18 09:35:00 PST -------
(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
------- Comment #31 From 2010-03-03 12:39:59 PST -------
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?
------- Comment #32 From 2010-03-03 12:53:42 PST -------
Nothing changed, adding full support is still blocked on having good answers to the questions in comments 5 and 6.
------- Comment #33 From 2010-03-03 13:19:09 PST -------
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.
------- Comment #34 From 2010-08-25 08:46:49 PST -------
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.
------- Comment #35 From 2011-05-10 01:26:03 PST -------
> 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)
------- Comment #36 From 2011-07-09 04:14:39 PST -------
(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)
------- Comment #37 From 2011-09-25 06:17:19 PST -------
(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>
------- Comment #38 From 2013-08-28 07:14:22 PST -------
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.