A Child’s Garden of XML

Despite the enormous enthusiasm XML has aroused in fields from literate programming to database management to business interchange, it has so far mostly missed its original target, the World Wide Web. The World Wide Web Consortium (W3C) designed XML for the web, but its early promise has been held up by the lack of a few key standards — notably XLink, its hypertext link mechanism
— and limited browser implementation. XML has barely moved out of the starting gate as a medium for web development.

Fortunately, new standards and new browers are finally making it possible for web developers to take XML seriously.  While there are still obstacles, XML is finally reaching the point where it can compete with and eventually overtake HTML, providing web developers with tools for reaching a much broader audience in more compelling ways.

Communicating with People and Computers#section2

HTML has done an excellent job of allowing computers to present information to people, and to respond to human requests in a fairly simple way.  HTML has been an almost total failure, however, in presenting information to computers in forms that they can reuse.  HTML document creation has long emphasized formatting, using a set of tools originally designed to describe documents.  Getting information into and out of HTML requires customized coding to convert data to HTML, and customized coding (on a per-site or even per-page basis) to get that information out again.  The early dreams of agents searching the web have been largely frustrated by the complexity of HTML and its inability to label information in contexts beyond those of documents.  The agents and search engines that do scour the web typically ignore the markup in documents they examine or pay attention to only a tiny subset.

XML provides both a clean structure for documents and an extensible framework for creating labels inside of those documents.  XML’s insistence on a basic syntax that is easily parsed makes it possible to open up the vocabulary without making documents impossible to process.  Because an XML document will (for the most part) produce the same labelled structure no matter what parser is used to process it, developers can build tools that operate on those structures. While XML is not itself a programming language, any more than HTML is, it creates data structures that are easy for programs to interpret.

Style sheets can describe how to present the information stored in XML documents, and users and programs can apply different style sheets to the same information to address different needs.  Programs can transform XML document trees into spreadsheets, database information, graphics, or whatever seems useful.  The same data can be presented and processed in many different ways using different style sheets or applications.  Even if a program wasn’t built to interpret a particular set of labels, conversions among labels and structures are made much simpler by XML’s insistence on clear structures.

So far, HTML browsers have been built to singlemindedly transform documents from a particular markup vocabulary into a destination presentation according to a particular set of rules.  XML allows developers to specify different presentation and processing rules for different types of documents.  This kind of work can be done within the traditional web browser framework, presenting information to people on screens and on paper, or it can expand beyond that into new territory, automating workflows, simplifying data transfers, and letting developers connect wildly different kinds of systems with a simple abstract format for exchanging information.

Sophisticated Linking#section3

HTML took the world by storm largely because it took the complexity out of hypertext.  Building a set of hypertext documents that connected to each other and to outside documents with hyperlinks became easy and painless.  Over time, however, web developers have begun to groan under the increasing costs that simple hyperlinking system inflicts on large-scale work.

HTML’s linking system puts all of the hypertext links inside of the documents that are the origin of the links, effectively scattering the linking information across enormous numbers of documents.  The documents targeted by those links know nothing of the documents that are linking to them.  If a target document moves or changes, the documents that were linked to it now contain broken links.  As sites grow larger, the costs of keeping track of all of these links in all of these documents — and fixing them when they break — grow larger.

While XML 1.0 itself doesn’t describe linking, XLink, a companion standard, does.  It provides a set of attributes that any XML vocabulary can use to create links between resources.  ‘Simple’ links provide the same kind of point-to-point linking that has been available in HTML, while ‘extended’ links provide much more complex but more manageable systems for linking resources.  XLink allows developers to create links that do things like:

• Connect sets of resources, not just two points
• Describe the connections within sets of resources
• Create links into (and out of) locations inside of documents without having the document author add anchors
• Specify behavior for links, and whether they need user intervention (like a click) to activate them.
• Create centralized link hub documents that describe all the links between a set of documents.

While delays in XLink’s completion have helped keep XLink out of the web browser, its recent stability promises a brighter future.

Manageable Information#section4

XML’s insistence on clean, clearly-marked document structures makes it possible for vendors to create systems that treat XML documents as tree structures rather than text streams.  Instead of treating an XML file as a long sequence of bytes, a storage system that understands XML can store it as a set of smaller pieces,  The implications of this change affect nearly every aspect of web development, from scripting to document storage to linking.

XML document structures simplify working with the Document Object Model (DOM), the heart of modern dynamic HTML (hopefully dynamic XML as well) implementations.  Programmers can reliably navigate and manipulate the tree structures created by XML parsers. This is a significant improvement from hoping that a particular browser’s interpretation of a given HTML document corresponds to the the interpretation that another browser sees.  XML already includes the kinds of cleanup that dynamic HTML developers have had to perform on their own documents.

The clear document structures also make it much easier to reference positions within a document.  Instead of having to mark positions within documents with ID and NAME attributes, XML developers can reliably point at abtractions like ‘the third LASTNAME in the fourth PARAGRAPH of the third SECTION’ and expect processors to find that location. XLink takes advantage of this flexibility to let developers describe links without requiring them to modify the origin and target documents.

XML opens new vistas in document management and storage.  HTML documents have been stored and transferred as large streams of text.  XML documents can be stored and transferred as fragments, referenced using the tree structures inherent in the documents.  Instead of editing an entire document, an author could edit a paragraph at the beginning without locking out other authors editing the middle and the end.  Readers who only want a single paragraph of a 100-page document can request only that paragraph, and do so reliably.  Tools that take advantage of these techniques are in their infancy, but XML reduces the costs of their development and usage significantly.  Document management becomes much simpler because XML markup structures are designed to be manageable.

The XHTML Bridge#section5

Impressed by the potential of XML, the W3C has begun moving its development of HTML into an XML syntax.  XHTML still uses the same vocabulary as HTML, but makes the same syntactical demands (case-sensitivity, clean nesting of elements, end tags for every start tag, etc.) as XML.  XML parsers can read XHTML documents — XHTML documents live dual lives as HTML and XML documents.

XHTML’s immediate impact on browsers is fairly minimal, though it begins a shift toward treating HTML as a legacy format.  In the longer term, however, the implications are enormous. XHTML 1.1, the next generation, is modularizing XHTML.  Devices that are unable to support all of HTML’s vocabulary will be able to use subsets, and identify to servers which subsets they are using.  XHTML documents will be able to include additional XML vocabulary, as developers create extension modules for XHTML, and XML documents will be able to use XHTML when they need to, allowing developers to apply the familiar vocabulary of HTML to information within XML documents.

XHTML brings many of the benefits of XML described above to HTML, and opens the door to wider use of XML as well.  XML retains an advantage in developers’ ability to define their own structures as needed, but XHTML provides a needed bridge between the well-understood HTML vocabulary and the wide-open possibilities of XML.

Browsable XML#section6

So far, most sites using XML for websites have transformed XML to HTML for presentation in the browser.  Most do it on the server, some that are supporting Internet Explorer 5 do it inside the browser, but the end result in either case has been an HTML view of information that started out in XML.  While standards for displaying XML without reducing it to HTML exist, Internet Explorer 5 has been the only widely-used browser to date to provide any support.  Its Cascading Style Sheets support for XML has been buggy, and provides no real means of creating linked documents. Extensible Stylesheet Language (XSL) support in the shipping version of Internet Explorer 5 has only provided for transformation to HTML within the browser, and has used an old version of XSL that no longer looks much like the standard.

Making XML documents part of the ’ordinary‘ browsing experience while preserving XML’s special capabilities requires more than tacking a conversion engine on to a browser.  The infrastructure has been developing slowly, and the next versions of both Netscape’s and Microsoft’s browsers may finally make that dream possible.  Netscape’s Mozilla is in the lead right now, providing CSS support for presenting XML on screen, a subset of XLink for connecting those documents, and support for the Document Object Model, exposing those documents to scripting.  The Internet Explorer developers are improving their product as well, though some key issues like support for XLink remain unresolved.

When these browser plans finally come to pass, web developers will be able to apply many of the skills they already have, using Cascading Style Sheets for layout, the Document Object Model for scripting, and the understandings of web interfaces they developed while building in HTML.  They’ll need to add a basic understanding of XML and XLink to that mix, but web development doesn’t require mastering the intricacies of either of these specifications.

The Future of the Web#section7

While predictions about the web’s future are always dangerous, it seems likely that XML is finally gearing up to move on its original target: the World Wide Web.  The W3C, widely acknowledged as the standard-bearer for HTML, is moving HTML into XML, while providing XML with the facilities it needs to match and surpass the hypertext capabilities of HTML.  Web developers will eventually face a very different world: a world where different vocabularies are a benefit rather than a cost, while rigid syntactical rules make those vocabularies both manageable and useful.