Monday, October 20th, 2008

Firefox 3 and XML

Category: Firefox

I’ve been delving back into the gnarly world of XML on the web lately and surprised to see what’s changed and what hasn’t. Coming up to speed on what’s new in this part of the Ajaxian world, I found a great article from IBM DeveloperWorks on what Firefox 3 brings to the table with XML. Some highlights:

“Firefox 3 introduces one huge improvement to basic XML parsing. In the past on Mozilla browsers, parsing an XML document was synchronous, blocking all operations on the document until it was fully loaded…To the user, this meant he starts to see how a Web page shaped up before the browser had completely processed the page; on the other hand, with XML documents the user saw nothing at all until it was completely parsed…In Firefox 3.0, construction of the XML content model is incremental, much as it is for HTML. This will make a big difference for practical use of XML on the Web.”

This is a good thing, since it means using XML on the web should be much faster as it is incrementally displayed now rather than appearing all at once at the end.

Another nice new feature in Firefox 3 is improved XSLT support (XSLT is a standard way to transform one XML document into another one, such as into HTML to display in the browser):

“The biggest win for those looking to use XSLT in Firefox is support for EXSLT, a set of XSLT extensions developed and sanctioned by the XSLT community and supported in many other XSLT processors. Firefox 3.0 adds support for a large subset of EXSLT, starting with the node-set function, an important workaround for XSLT 1.0’s most severe limitation. EXSLT is organized into modules, each of which defines several extension functions and elements.”

Lots of new EXSLT modules are now supported (including regular expressions!), which should make writing XSLT stylesheets much easier and more productive.

Even though XML on the web hasn’t had the best success, it’s still an important tool in the Ajax developers toolchain, especially those aspects that are cross-browser. Most developers don’t realize they can do XPath, XSLT, advanced XML, and more cross-browser; while you don’t usually need this power, sometimes its the perfect tool to solve a tough problem.

Finally, one of the things that would have helped XML on the web gain more adoption would have been to make working with namespaces easier. I stumbled across a great editorial today that I didn’t see reported on how this could have been done. For example, why didn’t they just standardize on prefixes like ‘svg:’ instead of long URLs? Its probably too late (though the HTML 5 working group is leaning in some of these directions), but the ideas in here are good:

XML Namespaces Don’t Need URIs

“The decision to identify XML namespaces with URIs was an architectural mistake that has caused much suffering for XML users and needless complexity for XML tools. Removing namespace URIs altogether and simply using namespace prefixes to identify namespaces would make it easier for people as well as software to read, write, and process XML.”

Posted by Brad Neuberg at 7:30 am
4 Comments

+++--
3.1 rating from 17 votes

4 Comments »

Comments feed TrackBack URI

Michael’s notes on XML namespaces are interesting, but it’s wrong to state that namespaces have to be URIs. They can be anything you like. For example WebDAV uses xmlns=”DAV:” as namespace.

However, there is a benefit to using a hierarchical scheme like URIs and that is the ability to assign names without a centralized authority. While on the surface it makes sense to use short prefixes like xhtml: or svg:, having to go through a central authority to standardize them would be an immense bottleneck. For example, we use xmlns=”http://mindtouch.com/2007/dekiscript” namespace when mixing our DekiScript XML into standard XHTML for processing. Since we own the domain, we claim right to its URI too. That makes it kind of simple. Although following Java’s convention–com.mindtouch.2007.dekiscript–would have been fine too if W3C had recommended that approach. Though advocating a different structure now doesn’t seem worth the cost of education.

Good examples of the compositional properties of XML namespaces are Atom and it’s various extensions such as GeoRSS and GData. That said, anybody who groks XML namespaces will eventually shake their head at their inconsistency as applied to attributes and elements. But that evil is much smaller than the overall benefits of XML namespaces.

Comment by Bjorg — October 20, 2008

Nice to see some improvements to the handling of XML. Whilst XML might seem the forgotten brother to JSON, it’s platform neutrality and web-service heritage still make it a great choice for delivering services direct to the browser and indeed, any application client. I make use of XML extensively in both my consumer app (http://applebox.com.au) and custom development, and find that whilst once I may have thought of switching to JSON to eek out a small performance gain in parsing and consumption, those days are well behind me.

Comment by simongil — October 20, 2008

Thanks for a great article.
I use XSLT and namespaces heavily in production on a project and I noticed extreme sluggishness in Firefox 3. In fact, FF3 seems slower than all other browsers while Firefox 2 is faster than any other.

Have anyone else come to same or similar conslusion?
Thanks in advance,
Hakan Bilgin

Comment by hbi — October 21, 2008

It’s a pitty that FireFox doesn’t implement the namespace:: axis !!!

I would like to use it for XForms to XHTML+Javascript conversion using XSLT. It works for IE and Opera but not for FF !!!

Comment by AlainCOUTHURES — November 26, 2008

Leave a comment

You must be logged in to post a comment.