XSLT document() Function Support (aka Lack There-of)

XSLT document() Function Support (aka Lack There-of)

Hi All,

So it's time to get down to business with gaining support for document() function inside the next release of Opera. As per my recent post to XML.com,

@ http://www.oreillynet.com/xml/blog/2007/09/opera_95_and_xslt_document_fun.html

Come on Opera! Are you a W3C web standards company or not? It’s not like you’re being asked to implement a deep down architectural change like XPath 2.0. This is an HTTP GET! That’s it! You’re a web browser company, you should be able to figure out how to do one of those, shouldn’t you?

Or is making a half a$$ed attempt at supporting web standards you may or may not have any interest in something we should just come to expect from this point forward?

It's been two years since you've added XSLT support to Opera, and in that same two years there have been MANY requests to implement support. This is a significant piece of the XSLT 1.0 specification that is missing. Can you please add this as a top priority?

Thanks in advance!

I think it's quite incredible that they haven't implemented it already. As you've said, it's an HTTP GET. It's what Opera does 99.9% of the time. Opera even supports XMLHttpRequest (and has for quite some time now), which has a much richer and more complex API than the utterly simple document() function.

Could not agree with you more than I do, Asbjørn!

Well, I also agree that document() should be supported. But unfortunately it turned out to be difficult with current codebase, even though it looks simple. It has a priority however and will be added when ready (not sure about Kestrel).

Hi White Lynx,

Thanks for your candid reply. I do recognize that things are not always as straight forward as they might seem from the outside, but would encourage you to place focus on delivering this as part of Kestrel. This is significant feature of the XSLT 1.0 that is used on a regular basis, *especially* as it relates to client-side processing of XSLT.

Would it be helpful if I were to provide a solid use-case, including the code base, of a project in which without the document() function will not work in Opera at all, yet with document() function support reduce the amount of Javascript code required by several hundred lines and the total size of any given page by anywhere between 60-100k+?

My personal belief is that if you see first hand the level of performance gains made possible when proper support for the document() function is in place it will become immediately obvious how much benefit your customer base can gain by providing this support. Please let me know (feel free to contact me directly), and I will be happy to provide you access to the mentioned code base.

One additional comment: Has anyone @Opera considered taking the same route Safari took, embedding libxml, libxslt and portions of libexslt directly and therefore gaining the benefits of a well tested, well supported, and well proven XML processing platform platform? If adding support for the document() function to the existing code base is as difficult as you suggest (and I have no reason to believe that this is not the case) then why not replace the XML/XSLT engine with something as proven as libxml/lib(e)xslt and gain all of the additional advantages that come along for the ride, ridding your team of the maintenance and support that for all intents and purposes would come for free?

Of course its no easy task integrating an external library, but from the sounds of it it may be a whole lot easier than the current situation you are faced with.

Just a thought.

It's clear without extra use-case examples that document() needs to be implemented, just it turned out to be nontrivial and delayed as developers were overloaded with other stuff. We got many bug reports due to document() function being unsupported and it has priority. I can't say more.

@ http://blogs.zdnet.com/web2explorer/?p=266

Håkon said in response that Microsoft has a responsibility to follow up on their promises to support CSS 1 and 2 - meaning they need to both implement the standards and also to fix the bugs they’ve introduced. Up till now, Håkon said, Microsoft’s CSS efforts have been "half-hearted".

Ed. emphasis added.

So my question is this: Do Mr. Lie's words apply to *ALL* standards? Or just the ones he had a part in developing?

Actually Håkon asked QA about status of document() function couple of times, so it is not like CTO does not care about things beyond CSS, but avialable resources are not infinite.

More specifically, differences and incompatibilities in CSS1 and 2 affect almost all web pages available today - client-side XSLT, while important, only affects a tiny subset.

There's no way any browser can implement all web technology standards at once, priorities have to be set.

@White Lynx,

There's not a single doubt in my mind that Håkon cares about *ALL* web standards, not just CSS. My point is to bring out the fact that he obviously believes that if a web browser company commits to a technology, they have a responsibility to see it through to the bitter end. And seeing it through to the bitter end requires doing things like setting aside the development of new technologies long enough such that the standards themselves can be finished out. Otherwise their "efforts have been "half-hearted""

It seems to me that what I am hearing is "yeah, we realize it's important, but not important enough for us to place resources on it that could be working on cool new *proprietary* features. I know for a fact that Håkon believes that browser interoperability should come before *ALL* else. And at this moment in time Opera does not interoperate with other *standards compliant* web browsers such as Internet Explorer, Mozilla*, and Safari.

That's unacceptable. Just ask Håkon,

@ http://www.theregister.co.uk/2005/02/11/hakon_on_ms_interroperability/

You say you believe in interoperability, Mr Gates. We'd like to believe you. But interoperability is hard work. It means writing test cases, discussing edge cases with other vendors, answering high school students, making the necessary bug fixes, and releasing upgrades. Writing the occasional email praising interoperability simply isn't enough. And your track record doesn't support your proclaimed beliefs.

And in a slightly modified format (changed words in bold), as per Mr. Lie's continued follow-up,

If you truly believe in interoperability, Mr Lie, here are some ways you can prove it:

Fix your document() function! Start by looking at the source code. Get disgusted. Clean up the mess.

@johnnysaucepn,

More specifically, differences and incompatibilities in CSS1 and 2 affect almost all web pages available today - client-side XSLT, while important, only affects a tiny subset.

Oh give me a phreaking break! That's statement holds about as much water as would suggesting to an HTTP server vendor that "Only a tiny subset of people will ever use DELETE, so implementing support isn't a priority.", or to a CSS vendor "Only a tiny subset of CSS developers will ever use '!important' so we don't need to place its implementation as a high priority!"

If a feature contained in a W3C web standard is optionable, it will be specified as such. The document() function is not an optionable feature! It's a critical and missing function in which makes Opera a non-standards compliant web browser. And they've been that way now for a month and one half shy of two years (XSLT 1.0 support was released as part of the initial Opera 9.x preview release on or around October 20th, 2005.) As non-trivial as implementing support for the document() function might be, it does not take almost 2 years to fix. You could write a complete standards compliant XSLT 1.0 browser in less than 6 months (this obviously doesn't include finding and fixing all bugs, but finding an obscure bug in the implementation of a feature is understandable. Not implementing that feature at all quite another.) so to suggest that in all of that time they just haven't been able to find the time to finish out the XSLT 1.0 spec is complete BS, pure and simple.

I didn't suggest such a thing, only that XSLT document() support is only of use to a small minority of developers, and an even tinier minority of users.

You'd be hard pressed to find many people, even in the web development community, that either is aware of, or uses, document(). I completely agree that it should be implemented, and that the spec implementation will never be good enough until it's done, but I also agree with the priority Opera's currently given it.

Opera has always taken a pragmatic approach to development - they've been strict in as much as they can, and followed proprietary extensions and incorrect implementations when they can't.

If missing one feature makes Opera a 'non-standards compliant web browser', then they all are.

@johnnysaucepn,

You'd be hard pressed to find many people, even in the web development community, that either is aware of, or uses, document().

You sure about that?

Not without defining 'many' or 'community' more rigorously than I have - which I'm not planning on doing!

I know you feel passionately about this, and that people you work with and share ideas with also feel strongly.

All I'm saying is, good things come to those who wait. I think it's unfair to dismiss all of Opera's efforts to implement all relevant web standards just because a lack of a specific feature happens to frustrate you.

You'd be hard pressed to find many people, even in the web development community, that either is aware of, or uses, document()

You'd be hard pressed to find any serious XSLT application that doesn't use the document() function. I've written numerous XSLT applications over the past seven years, and several of them would have been virtually impossible to implement without using document(). They were also all server applications, because of the abysmal support for XSLT on the client (and yes, I'm looking at Firefox here, as well as Opera).

Given that Firefox will soon have proper support for the language, it's about time for Opera to bite the bullet and implement the spec. After all, it is eight years old.

Originally posted by johnnysaucepn:

I didn't suggest such a thing, only that XSLT document() support is only of use to a small minority of developers, and an even tinier minority of users.

And again, you seem to be completely missing the point. This isn't a question of how many people use a particular feature. This is about standards compliance and browser interoperability. As it stands right now I can run the same XSLT 1.0 transformation file in Safari 2.x, any Mozilla-based browser past, I believe, 1.3, and IE 5.x and expect to get similar, if not exactly the same result. And while there are edge cases in which the interpretation of the spec results in variations in the output, not a single one of them will throw an error due to an unimplemented feature. Opera, on the other hand, does.

Originally posted by johnnysaucepn:

You'd be hard pressed to find many people, even in the web development community, that either is aware of, or uses, document(). I completely agree that it should be implemented, and that the spec implementation will never be good enough until it's done, but I also agree with the priority Opera's currently given it.

I guess browser interoperability is less important to you than it is to me. You see, with CSS I don't get,

CSS Processing Failed!

... when I encounter an unimplemented portion of the CSS spec. The resulting effect/layout may not be exactly what I was hoping for but it will still render the page, something I can then work around to gain consistent behavior across all major browsers.

With Opera and XSLT, I can't work around,

XSLT Processing Failed!

... no matter how much time I spend attempting to hack the source.

There is a HUGE difference between these comparisons, a difference you seem to be having a hard time coming to terms with.

Originally posted by johnnysaucepn:

Opera has always taken a pragmatic approach to development - they've been strict in as much as they can, and followed proprietary extensions and incorrect implementations when they can't.

Strict in as much as they can? Are you suggesting that in this particular case being strict about standards compliance is something that can reasonably be set aside? If so, how so?

Originally posted by johnnysaucepn:

If missing one feature makes Opera a 'non-standards compliant web browser', then they all are.

The problem with the above is that Opera has consistently touted itself as *THE* standards compliant browser, trash talking the other manufacturers (well, to be fair, primarily trash talking MSFT/IE) at any given opportunity when they place standards compliance any where other than at the top of the stack. Whether or not all the other browsers have corner case non-standards compliance issues is beside the point: Each of them are standards compliant when it comes to their XSLT processors, and Opera has taken every opportunity to champion themselves as the "defenders of all things standards compliant." Except for XSLT. They just make excuses. And they've been making them for 22 1/2 months.

Originally posted by johnnysaucepn:

All I'm saying is, good things come to those who wait. I think it's unfair to dismiss all of Opera's efforts to implement all relevant web standards just because a lack of a specific feature happens to frustrate you.

That lack of a specific feature renders the page *USELESS*,

XSLT Processing Failed!

... is quite a bit different than "Hmmm... that div container is 2 pixels off from where it should be."

We've been waiting for nearly two years for Opera to finish their standards compliant support for XSLT 1.0. That's a lot of patience. How much longer do you believe we should wait until we can expect to no longer see,

XSLT Processing Failed!

... when in every other browser we see exactly what we would expect to see when processing an XSLT 1.0 compliant transformation file?

Originally posted by xmlhacker:

There is a HUGE difference between these comparisons, a difference you seem to be having a hard time coming to terms with.

I have no trouble understanding your position. And I understand that you, (perfectly reasonably and by necessity) have an XLST-centric view of the situation. And I understand how frustrating it is for you. I'm not an Opera employee, and I can't speak for them.

XSLT is important, but not high-profile. I'm sure Opera devs would much prefer to be spending their time implementing the missing parts of XSLT rather than fielding complaints about how "Yahoo! mail doesn't work", and "why can't I have rounded corners like I do in FF", and "why can't I use my NTLM proxy server".

Unfortunately, users are a pain, and they pay the bills.

For what it's worth, missing CSS features are just lucky in that the lack of them doesn't cause the failure of the document content. And HTML has all sorts of contingencies for incorrect handling. XSLT is rather less forgiving by nature.

I'm sorry that Opera hasn't fully implemented your pet standard, but that doesn't undo the work they've done implementing others.

Originally posted by johnnysaucepn:

I'm sorry that Opera hasn't fully implemented your pet standard, but that doesn't undo the work they've done implementing others.

My pet standard? You seem to be of the belief that I am some Lone Ranger-type coder, a rare and obscure developer of a rare and obscure language. The truth of the matter is that Opera is so late in the game with all of this that they seem to misunderstand just how much XSLT as a language and, as it relates to this thread, the document() function is used. For example, from the text of a recent response from Sam Byland to XSL-List,

Out of 416 .xsl files in our system, there are 1626 occurrences of the string "document(" using a simple DOS search (findstr /s /c:"document(" *.xsl). To be fair, a small handful of these appear in comments....

The fact of the matter is that if there is any single function used more often than another the document() function would be that function. And to suggest such as a phrase as "[my] pet standard" suggests you either need to do some research on the usage statistics of the XSLT language or stop attempting to argue about a subject matter in which you have absolutely no understanding of.

Originally posted by xmlhacker:

stop attempting to argue about a subject matter in which you have absolutely no understanding of.

Respectfully, I would ask you not to assume what I do or do not have an understanding of, simply because I have a different perspective.

I have pet standards, and I make no qualms about it - I'm extremely interested in CSS3 and SVG, and I've been dying to finally get my hands on the new ECMAScript 1.5 getters and setters support. They may not be important things to you, but they are to me. I don't have a problem with that.

On a side note, and aside from this discussion, I would be very much interested in those usage statistics you mentioned. Do you have a link?

Originally posted by xmlhacker:

So my question is this: Do Mr. Lie's words apply to *ALL* standards?

Håkon is speaking about Microsoft's CSS responsibility to the Web. To say otherwise would be to take him out of context.

Originally posted by Turin:

Håkon is speaking about Microsoft's CSS responsibility to the Web. To say otherwise would be to take him out of context.

And you actually believe that, don't you? That's truly amazing because while his comments are directed as an attack on Microsoft's CSS inefficiencies, his focus is placed on web standards in general, using that exact phrase countless times. To suggest that it's okay for Mr. Lie to attack MSFT as it relates to the CSS standard while at the same time protecting him from counter-criticism based on a "contextual foul" is ludicrous, pure and simple.

One thing that is interesting to me about standards such as SVG is that they are much more exciting within the context of something like XSLT. For example, if I could take an XSLT and load a set of SVG documents, I could do things like lay them on top of each other in some dynamic means or pull out metadata, or a million other things to transform the SVG XML.

I think the problem with something like SVG or any XML based specification is that outside of XML itself, it is pretty much just some easily parseable format. But when you consider tools such as XSLT when analyzing something like SVG, the gains become more self evident and what's more, you get cool new features.

Now I haven't been following this topic too terribly closely, but it sounds like adding a bit context regarding XSLT and using the document function might help to see its value in light of obvious transformations (ie such as an Atom/RSS feed) as well as more obscure transformations (ie turning an SVG image into a slick interactive connect the dots game ).

Hope that helps expand the conversation a bit.

Originally posted by johnnysaucepn:

Respectfully, I would ask you not to assume what I do or do not have an understanding of, simply because I have a different perspective.

A perspective in which suggests in no uncertain terms something that is absolutely and utterly absurd.

As per a follow-up response from Dr. Michael Kay on XSL-List speaking specifically to your comments regarding > "You'd be hard pressed to find many people, even in the web development community, that either is aware of, or uses, document()."

Sounds like a country yokel in a remote Yorkshire village saying you'd be
hard pressed to find anyone, even in Sheffield, who has ever heard of
London, let alone been there.

Sorry if the choice of place-names doesn't travel...

Michael Kay
http://www.saxonica.com/

If you make comments that showcase the fact that you don't know what you are talking about, that's not an assumption, that's a fact. Sorry if you don't like it, but I'm not the one who attempted to use fiction as fact as part of my argument.

Originally posted by johnnysaucepn:

I have pet standards, and I make no qualms about it - I'm extremely interested in CSS3 and SVG, and I've been dying to finally get my hands on the new ECMAScript 1.5 getters and setters support. They may not be important things to you, but they are to me. I don't have a problem with that.

XSLT 1.0 has been a specification for eight years! CSS3 hasn't even reached final recommendation status, and SVG has never reached any sort of critical mass and therefore can't be seen in the same light as a standard such as CSS, XML, XSLT, and JavaScript. And as far as JavaScript is concerned, I agree, getters and setters are *GREAT*! But, once again you are missing the point, which has *EVERYTHING* to do with cross-browser incompatibilities, or in other words the XSLT code I write can be used in Safari, IE, and Firefox, and minus some edge cases related to different interpretations of the spec, the output is exactly the same in each of them, where as in Opera I get the aforementioned XSLT Processing Failed! This isn't a question of "Hey, this is a really neat feature, but without it I can work around it" and instead without support XSLT processing in Opera is *DEAD*. You can hack around the various nuance's between each browsers implementation of CSS and Javascript, but you can't hack around XSLT Processing Failed as it relates to the functionality provided by the document function. In other words, there is no other way for me to gain access to an external document inside of the transformation file where as there are ways to get things to line up correctly in CSS, or implement pseudo class effects using DHTML events and Javascript, or etc.

In short: This isn't a "wouldn't it be nice" feature. This is a showstopping bug pure and simple and it needs to be fixed.

Originally posted by johnnysaucepn:

On a side note, and aside from this discussion, I would be very much interested in those usage statistics you mentioned. Do you have a link?

http://www.biglist.com/lists/xsl-list/archives/200709/msg00125.html

Originally posted by xmlhacker:

In short: This isn't a "wouldn't it be nice" feature. This is a showstopping bug pure and simple and it needs to be fixed.

Also in short: I completely understand and completely agree that it is a showstopping bug in XSLT processing, and needs to be taken care of. If you think that I believe otherwise then you may have completely misunderstood everything that I have written so far.

Conversely, I'm pretty sure you understand that Opera has limited resources and market-driven priorities, so what makes you think we have anything to argue about?

Sure, 'hard pressed' was of course the wrong phrase to use, I didn't think my words would get quoted so literally on another forum.

The heaving, ignorant, unwashed masses currently don't hit many XLST-based sites in daily browsing. I, too, hope this will change, as it's a powerful, exciting technology that I could make good use of myself. But in the mean time, I will leave you and this thread in peace.

Oh yes please support document()!!!
Even dumb Firefox AND IE supports this...

I, too, came across a "XSLT processing failed!" today.
So I came here to understand why and found the thread. Nice discussion, johnnysaucepn and xmlhacker. The funny thing is you're both right with valid arguments. Now, whether the arguments hold in reality, I don't care but they seem right.

The document() function is absolute necessity. Especially if the standard is eight years old and if Opera has been dragging feet for two years or close.
Quite a disappointment for me to discover this, I must say.

Opera is clearly now behind the other 3 browsers in its support for XSLT. However Opera's support of XSLT is good enough to make it useful.

Here is a link to a site in prerelease that depends on XSLT rather extensively

http://arsmc.org/documents/gatewayentry.xml

This site works on IE6+, Safari 3+, Firefox 2+, and Opera 9+.

Opera needs support for the document function and to provide more reliable support for include and import.

Safari 3 seems to have passed both Firefox and Opera in their support for XSLT 1.0.

I want to thank White Lynx for his advice on how to make the above site work on Opera 9 and above.

I am hoping all 4 browsers companies with improve their support for XSLT 1.0 and quickly move to supporting XSLT 2.0.

Improving support for XSLT is simply much more important for the future of browsing than improved support for CSS.

In my opinion until browsers support XSLT 2.0 we have not moved into the 21th century of browsing.

Originally posted by john.perkins:

Here is a link to a site in prerelease that depends on XSLT rather extensivelyhttp://arsmc.org/documents/gatewayentry.xml

This page looks in Opera 9.5 (9523) just plain empty.

You are correct

http://arsmc.org/documents/gatewayentry.xml

does not work in OPera 9.5 but a smaller version

http://arsmc.org/documents/gateway.xml

does work in 9.5

XSLT on large XML files seems to fail in Opera.

John Perkins

Dear Opera folk,

First, thank you for your excellent browser.

I understand your position re: client-side XSLT not being your top priority. I think that's reasonable. However, I do think it is now the appropriate time for you to invest the relatively small amount of resources necessary to add support for the document() function. It is, after all, a very important aspect of the standard that many of us client-side developers really would like to be able to depend on in all modern browsers.

You are now behind all the other major players in this particular case. That should be a sign. Please take the time to do this now... i think it is warranted at this time. I hope you will agree.

Thanks for listening, and thanks again for a fantastic browser.

Todd Ditchendorf

Based on how the major browsers handle the xml/xslt for the pages of arsmc.org/gatewayentry.xml I would rank the browsers XML/XSLT as follows:

1) IE6 and IE7
2) Safari 3 beta
3) Netscape 9
4) Opera 9.23
5) Firefox 2 and 3 beta (Scroll bar problem)
6) Opera 9.5 beta (Inability to handle xslt transforms for large xml files)
7) Safari 2 (No support for XSLT in Javascript)

I am amazed how much better Netscape 9 is than Firefox 2 or 3 at rendering the XSLT transforms.

Both Opera and Firefox are out classed by other browsers when it comes to support for XSLT.

John Perkins
arsmc.org

http://my.opera.com/desktopteam/blog/2007/11/16/even-more-work

And xmlhacker gets a namecheck!

YOU ROCK, OPERA!!!!

http://www.oreillynet.com/xml/blog/2007/11/operadocument_function_when_yo.html

(thanks for the shoutout! )

johnnysaucepn: Thanks for putting up w/ my grief! Given that I saw support for getters and setters in javascript in a recent weekly, something tells me we both have something to celebrate

Have you tested it yet? How well does it work?

@johnnysaucepn,

>> Have you tested it yet? How well does it work?

Yup. > http://www.oreillynet.com/xml/blog/2007/11/operadocument_function_when_yo.html#update-one

Had to fix an issue with my code, but that's a +1 in favor of Opera for building such a kick a$$ error console and standards compliant browser.

Hello! I'm not good writing in English. I apologize because this thread is out of date.
I have a problem with the "document()" function.
It does not work when the output method is "xml".
This is a serious error because the function is available when the output method is "html".
This prevents work with "Opera" to implement a "Client-XSLT" when the output is "XHTML".

My Opera:
Versión: 9.64
Compilación: 10487
Plataforma: Win32
Sistema: Windows XP
Java: Sun Java Runtime Environment version 1.6
XHTML+Voice: Conector no cargado
Identificación del Navegador: Opera/9.64 (Windows NT 5.1; U; es-LA) Presto/2.1.1

It does not work when the output method is "xml".

It would be good to create a different thread, but anyway. It works. On my site as an example:

http://serenareem.net/
http://serenareem.net/transform/base.xsl

Search for "document(" in base.xsl.

Thank you, Haruka aka Ser!
You are absolutely right. I regret not having had prior examples like yours to test.
The problem is not the output method.
The problem lies in doctype attributes.
I have:

<xsl:output
method="xml"
omit-xml-declaration="yes"
doctype-public="-//W3C//DTD XHTML 1.0 Transitional//EN"
doctype-system="http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"
indent="yes" />

Without "doctype-public" and "doctype-system", it works.
Fortunately, it appears that IE is maintained in "standard compliance mode" even without them present.
But with them, in all other browsers except Opera the function works.