December 11, 2008

Firefox 3 and XML

View the technorati tag: 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."

No comments: