Standardizing on libxslt for XSLT support

[Elliott Sprehn]

We have a bunch of abstractions to make our XSLT support be generic and not specific to libxslt so in theory we could swap out the implementatios (ex. TransformSourceLibxslt.cpp). I think these were used by some webkit ports to use different libraries, specifically I think QT used a different XML library.

Do we want to support that going forward? Can I rename these files and get rid of all the void* pointers on them that were for the abstraction?

Can I do the same thing for libxml2 and the XMLDocumentParser? :)

- E

[Eric Seidel]

Correct. libxml2 and libxslt are the one-true way for now.

It's been on my list of code to delete for a while.

The XMLDocumentParser can be greatly simplified once we remove the
QXML support. :)

[Ojan Vafai]

Would be great if we histogrammed XSLT usage. Maybe we could stop supporting it entirely.

[PhistucK]

Please, no.

☆PhistucK

[Ojan Vafai]

Do you know of websites that use XSLT?

[PhistucK]

No. I do not have any source (I would have elaborated if I did), but I feel that this is not the right decision. I know a feeling is not enough. ;)

XSLT is supported by all of the major browsers.

It is very useful within Chromium for showing an XML tree when opening raw XMLs with no XSLT definition, for example.

I understand you want to clean up the platform. I do, too, but let us not be so overzealous/greedy. ;)

☆PhistucK

[James Smits]

The Google Search Appliance uses XSLT for UI.  

I am not a chromium developer, so apologies if my response is unwarranted. 

https://static.googleusercontent.com/external_content/untrusted_dlcp/www.google.com/en/us/enterprise/mini/library/MiniSearchInterface.pdf

[Dirk Schulze]

On Apr 23, 2013, at 10:59 AM, James Smits <james...@gmail.com> wrote:

> The Google Search Appliance uses XSLT for UI.
>
> I am not a chromium developer, so apologies if my response is unwarranted.
>
> https://static.googleusercontent.com/external_content/untrusted_dlcp/www.google.com/en/us/enterprise/mini/library/MiniSearchInterface.pdf

XSLT makes perfect sense on the sever side and is indeed used there. Are you sure this interface requires support on the client side?

Greetings,
Dirk

[James Smits]

That is what I recall, but maybe not. I worked with the Search Appliance a long time ago, so maybe memory fails me.

[Daniel Bratell]

Den 2013-04-23 19:24:34 skrev Ojan Vafai <oj...@chromium.org>:

> Do you know of websites that use XSLT?

(jumping into the middle of the thread)

As one of the developers of Presto's XSLT engine[1] I've heard of and seen
a few sites that use XSLT, but typically they are experimental, internal
to a company or network, or minor sites by misguided web-developers.

That said, I don't believe in going around and cutting small features that
has been around in all browsers for a long time. Somewhere there are
people that depend on them and content that will be unreachable once
support is dropped.

/Daniel

[1] We were always pleasantly surprised when we once every six months got
some kind of feature request or bug report showing that people actually
used xslt. :-)

[Eric Seidel]

I implemented XSLTProcessor in WebKit as one of my first official
tasks on the Safari team. It was for some internal IBM/PeopleSoft
site iirc. Very rarely since have I run across sites which use
either.

XSLT and XSLTProcessor are not modern web-design patterns (and their
implementations in Blink are poor at best). They're synchronous APIs
which like sync XMLHttpRequest should be consider deprecated, and
(hopefully) eventually removed from the platform.

I strongly support getting numbers on our XSLT
processing-instruction-based usage, as well as XSLTProcessor usage.

My suspicion is that neither can be removed from the platform at this
time. But both are probably good opportunities for later removal or
replacement with JS-based polyfills.

I expect removing the need to ship libxslt as part of Chrome to be a
small (but non-trivial) binary size win.

[Ojan Vafai]

On Tue, Apr 23, 2013 at 2:09 PM, Daniel Bratell <bra...@opera.com> wrote:

Den 2013-04-23 19:24:34 skrev Ojan Vafai <oj...@chromium.org>:

Do you know of websites that use XSLT?

(jumping into the middle of the thread)

As one of the developers of Presto's XSLT engine[1] I've heard of and seen a few sites that use XSLT, but typically they are experimental, internal to a company or network, or minor sites by misguided web-developers.

That said, I don't believe in going around and cutting small features that has been around in all browsers for a long time. Somewhere there are people that depend on them and content that will be unreachable once support is dropped.

Whether we can cut the feature or not depends on whether there's enough content that uses it. Small, unused features add up in terms of binary size, code maintenance and security footprint. 

I don't have any intention of cutting any feature that has significant usage.

[Ola P. Kleiven]

Daniel Bratell <bra...@opera.com> skreiv Tue, 23 Apr 2013 23:09:38 +0200

> Den 2013-04-23 19:24:34 skrev Ojan Vafai <oj...@chromium.org>:
>
>> Do you know of websites that use XSLT?
>
> (jumping into the middle of the thread)
>
> As one of the developers of Presto's XSLT engine[1] I've heard of and
> seen a few sites that use XSLT, but typically they are experimental,
> internal to a company or network, or minor sites by misguided
> web-developers.
>

Looked through some of our old bug reports. Most sites are defunct or
changed, but found a few still having traces of it (at least importing
some resource)

http://support.lenovo.com/en_US/downloads/default.page
http://www.staples.com/All-Laptop-Computers/cat_CL167289
http://www.kanzaki.com/ns/music
http://www.opengl.org/sdk/docs/man/

--
Ola P. Kleiven
WebStandards
Opera Software ASA

[mart...@graphity.org]

XSLT hasn't become widespread in client-side applications because of poor support in browsers, not the way around. XSLT makes just as much sense on the client-side as on the server-side, if not more.

Saxonica has a cross-browser implementation of XSLT 2.0 processor, which will hopefully improve the situation:

http://www.saxonica.com/ce/index.xml

Overall, the trend to push for APIs in imperative languages such as Javascript instead of declarative/functional languages like XSLT is worrying. The latter has much better characteristics from the theoretical point of view, which is becoming important with the growing need of parallelism.

Martynas

graphity.org

[drjohnp...@gmail.com]

Oh, please don't drop support for client-side XSLT. TEI Boilerplate (https://github.com/GrantLS/TEI-Boilerplate) uses it. And I have a another, larger, TEI rendering app, currently in testing, that uses client-side XSLT. (In fact, Chrome has been the primary development platform.)

[kor...@gmail.com]

Please, no! The company I work for isn't very publicly visible, but we are fairly crucial within our industry. The client-side engine for our main display framework is heavily dependent on client-side XSLT support. The great strength of client-side XSLT (particularly XSLTProcessor) that we've found, is for creating and re-creating templated content on persistent displays, while only requiring updates to the underlying data. You make one AJAX request for, say, the XML data for a data grid, run it through the XSLT to get the HTML, and dump the result directly into the display. This can be done repeatedly without unloading the window, and the HTTP payload for each request is (sometimes significantly) lower than if we were to transform on the server and return the HTML in the AJAX request, since you're only transmitting the underlying data. The XSLT transformation itself is incredibly fast, much faster than any Javascript-based processing we could possibly do on a similarly structured payload, as XSLT engines have been optimized and re-optimized over the years to be very efficient.

We JUST got our system updated and polished to support Chrome/Safari, even with its XSLT quirks (no xsl:import, document() support). PLEASE don't yank the rug out from under us now! I know XSLT isn't as attractive as HTML5 or whatever, but it's been around and supported by all the major browsers for a long time, and it does have its merits. The reasons for keeping XSLT support in WebKit FAR outweigh the reasons for removing it, in my opinion.

[alain.c...@agencexml.com]

XSLT support in browsers is a key element for my XForms implementation (XSLTForms). Even XSLT 1.0 is not as easy to use as XSLT 2.0, it is very fast in browsers and I use it to compile XPath expressions into Javascript objects. There is no possibility to associate, let's say, a page or a JS file to JSON data while it's easy to associate a processing-instruction to XML data and apply an XSLT stylesheet.

-Alain

[michae...@gmail.com]

How about going forward instead of backward? XSLT 1.0 implementations in the browser are pretty dated, not just because XSLT 1.0 was superseded by 2.0 about six years ago, but also because they only do a very small part of what a modern web application needs to do - they convert XML to HTML and then walk away from the scene. Not much use in an Ajax/Web 2.0 world where you still end up doing all the interesting stuff in Javascript. By contrast Saxon-CE's cross-browser implementation of XSLT 2.0 doesn't just create an HTML DOM, it does all the subsequent event-handling as well, which means you really start to save a lot of coding when you want to generate an interactive page. So my suggestion (as an interested party!): drop the current XSLT 1.0 engine and integrate support for Saxon-CE.

[Ojan Vafai]

As I said earlier, we won't seriously consider removing a feature that would break a lot of sites. All we're doing right now is gathering data. From the comments on this thread, it sounds likely that there will be enough usage that we won't remove it. There's no harm in getting the data on usage though. It's possible that we'll gather the data, find that a lot of sites use it, and decide to invest *more* in XSLT. 

[zup...@googlemail.com]

Am Mittwoch, 24. April 2013 16:41:56 UTC+2 schrieb drjohnp...@gmail.com:

Oh, please don't drop support for client-side XSLT. TEI Boilerplate (https://github.com/GrantLS/TEI-Boilerplate) uses it. And I have a another, larger, TEI rendering app, currently in testing, that uses client-side XSLT. (In fact, Chrome has been the primary development platform.)

 
I think TEI is a perfect example of why XSLT is useful for rendering such data.  TEI's structures are quite flexible and can become quite complex.  XSLT with its templating and especially XPath based matching and querying mechanisms is a perfect tool for managing the complexity.  Doing similar matching or querying on XML or equivalent JSON structures using JavaScript is definitely not something I'd be keen on doing.

We're working with similar data and take advantage of XSLT as well as bleeding edge HTML5/SVG/CSS3.  Server side transformations are not an option, not only because we want instant updates that reflect changes to the data, but also because our clients must be able to work in situations where they don't have network access.

[kor...@gmail.com]

I would be in support of this, but if and only if the performance of XSLT 1.0 transformations in Saxon-CE can match or beat the performance of the same transformations in XSLTProcessor (libxslt). I know that may seem a bit unfair on its face, but performance is and always has been the bottom line for most of us writing client-side XSLT.

[mdy...@gmail.com]

I would add a note about performance here. Once compiled, XSLT transformers are extremely fast in Saxon; they might not be able to post the same performance of any well-done C implementation but have proved that they can serve multiple concurrent clients in a server environment.  As frequently as new xsl styelsheets present themselves to a browser, the performance difference would hardly be noticeable on a client system.  

One might even consider a strategy of passing XSLT 1.0-declared stylesheet to libxml and reserving the invocation of Saxon-CE  for those with 2.0 declarations.

[michae...@gmail.com]

On Thursday, April 25, 2013 10:32:40 PM UTC+1, kor...@gmail.com wrote:

I would be in support of this, but if and only if the performance of XSLT 1.0 transformations in Saxon-CE can match or beat the performance of the same transformations in XSLTProcessor (libxslt). I know that may seem a bit unfair on its face, but performance is and always has been the bottom line for most of us writing client-side XSLT.

It would certainly be interesting to make some comparative measurements. Clearly Saxon-CE starts with a disadvantage in that it has to be downloaded as nearly 1Mb of javascript source code and compiled before you can start doing anything with the XSLT; I would hope that an integration project could eliminate that overhead. Once that overhead is removed, it would be very interesting to compare (many simple transformations are dominated by XML parsing speed, so there might not be much difference). And of course performance is not just raw transformation speed, but also things like working asynchronously when fetching multiple source documents or stylesheet modules from the server. 

[Eric Seidel]

I believe discussions of the merits of XSLT belong on some other list. :)

To finally put this thread to rest:

- As Ojan noted, we will not be removing any features of the Web
Platform which have significant usage, and no one is proposing
removing XSLT at this time. XSLT's usage is likely well over that
bar. Ojan is going to add some counters and we'll have better numbers
to report soon.

- I cannot personally recommend authors use XSLT (despite being the
author of WebKit/Blinks XSLTProcessor/XSLT support). The
non-incremental nature of XSLT (you pass your whole document to XSLT,
wait synchronously for it to return the transformed document) combined
with WebKit's poor implementation (WebKit parses the whole XML, then
re-serializes it to a string, then it gets re-parsed by libxml,
processed by libxslt, and then re-serialized for re-parsing by
WebKit!).

If client-side XSLT is to have a growing-future on the web (which it
very well may) I recommend interested parties write amazing
(JavaScript) libraries to do incremental XSLT processing and encourage
site authors to use them in lieu of browser native support.

Blink can-not/should-not provide every feature of the Web natively in
C++ and we're continue to try and move more and more of our code into
higher-level abstractions. If someone writes an amazing (and
license-compatible) JS implementation of XSLT, maybe we'll ship it as
part of Blink some day. It would be hard to perform worse than our
current implementation on top of libxslt!

Thank you all for your thoughts. We'll report back numbers when we
have some to report.

[back...@gmail.com]

> Thank you all for your thoughts.  We'll report back numbers when we have some to report

It's been a couple years. Curious if there were every any number reported.