Oliver Steele

XML schemas change over time, for the same reasons that library APIs evolve in programming language. Over time, the schema designers introduce new content, and change or remove existing content, as they acquire greater familiarity with the domain model and the use cases, as they add additional functionality, and as they fix design bugs.

Often it is necessary to maintain instances of old versions alongside instances of new versions. (I’ll discuss why this is necessary.) An example is XSLT, where XSLT 1.0 and XSLT 2.0 documents may be present on the same file system. Other examples are XHTML, and SVG. The presence of instances of multiple schema versions frequently requires the presence of descriptions of multiple versions, and the problem of maintaining these multiple schema versions arises.

An A Fresh Canvas I argued that there’s a human-factors advantage to allowing an XML document to contain names from multiple namespaces without requiring namespace prefixes on the elements from all but one of them. In What’s in a Namespace I looked at how namespaces and namespace imports work in programming languages, which generally allow both qualified imports (like XML Namespace) and unqualified imports as well.

I also said that I would demonstrate that unqualified imports could be added to XML in a well-defined way, if certain conditions were met. (The conditions are that the set of names in each namespace is known when the document is processed. This is the same condition that programming languages such as C++ and Java, that resolve the namespace of unqualified names at compile time, impose.) Here’s where I make good on that promise.

Last week I discussed the fact that “namespace hygiene” — the use of XML namespaces — would cause a simple Laszlo program such as this one:

[code language=”xml”]

Dave Hyatt has been taking some heat for introducing new HTML tags into the set of tags supported by Apple’s Dashboard. Read the post that started it here. Eric Meyer and Tim Bray take issue with the proposal here and here, and Hyatt responds here.

As the author of an XML-based presentation language, this is an issue dear to my heart. Like Dashboard, LZX is intended for the creation of cinematic interfaces — HTML-embedded applications that are more interactive and have a design esthetic beyond what can be achieved with portable HTML+CSS. And like Dashboard, LZX applications leverage current browser technology.

I recently wrote a pretty-printer for LZX, in XSLT. Here is the source code to the Laszlo Weather application; click on “View Source” on the Laszlo Demos page for other examples.

Don Park writes:

I had been expecting baby talk versions of complex XML formats to emerge for sometime now. It hasn’t happened yet so I am left with scratching my head. The idea is simple enough, take a complex format and create a user-friendly version that maps to the more complex version via an XSLT file.