YOU ROCK!!! :D

(more detail as to why below)

An interesting conversation started by Robert Koberg began to take place last week on XSL-List in which Robert revealed that he had added some XSLT capabilities to the trunk of the dojo toolkit. Of course, he ran into some problems with Opera’s XSLT implementation, something that I haven’t been shy in bringing to the surface here on this blog.

Well, today, that conversation just got a tad bit more interesting.

via a follow-up comment (not in the archives yet) to Robert’s inquiry in regards to whether or not Opera had plans to provide an implementation of the document() function, our very own Michael Smith reports,

> Is document() going to be added at some point?

Yes, absolutely. I wish I could say exactly when, but I don’t know.

> My use case is that in some transformations I use a
> configuration or simple stub (’‘) XML file as the main
> source and pull in other files based on the config or
> parameters. This way you get around loading a big dom in JS and
> only load a processor optimized dom for the transformation.

Sounds like a perfectly valid use case. I find the lack of
document() support to be a fairly big obstacle myself. But then
(at least in the work I do with XSLT) I guess I also find lack of
support for turning XSLT 1.0 result-tree fragments into real node
sets to be a equally big obstacle. Opera 9.02 does do the right
thing there by supporting exslt:node-set().

> If you want to check out the dojo implementation, you would need to get
> the trunk from SVN (or wait till .4 comes out, which should be soon). In
> the dojo/tests/xml/ directory you will find test_XslTransform.html which
> has 3 example transformations. The first one uses the document function
> and therefore fails. The other two do not use document() and work as
> expected.

OK. I’ll check the sources from SVN and try it myself. But I do
know for certain that any test case which relies on document() is
currently going to fail in Opera.

> I will let the dojo folks know about the document() limitation.

Thanks. And as soon as support for document() is finally added, I
can guarantee you that Opera will be announcing it widely to the
developer community.

Folks, I am a BIG fan of Mozilla/Fx for LOTS and LOTS of really good reasons.

Like Michael, the lack of the document() function in Opera’s implementation of XSLT 1.0 was a big obstacle in my book, as there is simply too many things that you can not do without the ability to access an XML document outside the context of the current XML document that is being processed.

That said, his point in regards to Result Tree Fragments is quite valid, and as I have pointed out before, something that must be seen as an absolute blessing, and as such, something I am quite grateful for.

And with all of this said, two things,

- Question to Opera: How and when did you acquire the talent and skills of Michael Smith?
- THANK YOU!!!! (for both finding a way to bring Michael Smith into the Opera fold, and for showcasing the fact that you REALLY do care about web standards other than those you have a personal preference for by delivering a full implementation of XSLT 1.0)

So back to my point regarding Moz/Fx…

As much as I love Moz/Fx, and as good of a family of browsers that Moz/Fx represent,

Opera is even better. They have a different focus, and therefore in some respects, Moz/Fx is better. But from the standpoint of providing the best overall web browsing experience?

Hands down… Opera beats EVERYBODY!

Opera, this really means a lot to see you put forth this effort. Again, thank you!