Non-Extensible Markup Language

XML's steady descent into obscurity has become more and more apparent over the last few years. Developers, tool vendors, and browser implementers have all embraced HTML as the web's markup language, built on a substrate of JavaScript. Nothing epitomizes this shift more than the recent rise of web components: instead of standards committees dreaming up domain-specific XML vocabularies and hoping one day browsers would incorporate them, web components and the extensible web principles they embody allow authors to empower HTML with the same abilities XML once promised. The HTML of today is a truly extensible markup language. Where XML failed in this mission, both historically and practically, the web ecosystem routed around the damage of XML's influence by making HTML better suited for extensibility than ever before.

Mending Fences and Saving Babies

The harshest squabbles are fraternal, and as fraternal squabbles go, the one between the proponents of XML and HTML has been at times quite brutal. This kerfuffle has opened large rifts in what is largely a like-minded community. The differences between XML and HTML are genuine, especially when considering not just the markup but the full family of technologies that have grown around them. But do they really justify animosity? Both XML and HTML have created strong solutions to varied problems often ignored by other angle bracketists. Their many commonalities mean that the XML and HTML communities need not throw away one another’s babies in a big slosh of bathwater. It is time for a candid conversation about flaws and limitations, and from there to mend fences. In this paper we look at some mythical preconceptions that each community has about the other, go through a number of topics that show where there is value in “looking over the fence”, and reach what is hopefully a pragmatic conclusion as to what each community needs to do.

XML on the Web

In the beginning, many presumed we would move to a world where XML documents and the applications that processed them would proliferate across the Web. The Web looked like a bright place for markup; technologies like XSLT made their way into the browser and linking standards were on their way. Yet, it didn’t happen. As browsers strengthened their ability to process information, render HTML documents, display media assets, and deliver applications, the role of XML was either pushed to the other side or used as a way to deliver data to applications within the browser via AJAX. The potential mismatches between the wants of the Web developer and the generic, impoverished nature of the DOM led to the development of JSON. In places where they might once have used XML, web developers have moved in droves to using JSON and HTML. XML has been removed from its role to convey data to applications, shunted to the server, and labeled legacy by many. With an uphill, generational challenge to bring it back within favor, the fundamental question is: Do we really want XML on the Web?

The Library of Congress Recommended Format Specifications

The “Library of Congress Recommended Format Specifications” describes formats which it will collect to ensure the preservation and long-term access of the creative output of the nation and the world. The specification covers textual works and musical compositions, still image works, audio works, moving image works, software and electronic gaming and learning, and database/databases. For each of these categories a list of preferred and acceptable formats, in descending order of preference, is provided. Formats for textual works include XML, EPUB, and HTML. After introducing the specification we discuss why it was created, the considerations in ranking the various formats for electronic books and serials, and how the Library expects the policy to be used.

Practical Processing of HTML5 as XML and XML as HTML5

Whilst the HTML5 and XML specifications share a superficially similar syntax, they have very different design goals, cultures and supporting technology stacks. This paper provides two practical examples of projects that benefited from the combined use of XML and HTML5 technologies. Both projects make clear distinctions between the areas of responsibility for each technology and employ specialized methods and tools to integrate between the two. We show that the ability to exploit both XML and HTML5 resources can significantly reduce development effort and provides for more flexible solutions.

What do we still lack?

Hypertext on The Web is ubiquitous; it is hyperlinking that makes it a web. The current hypertext Web is useful and comfortable, but it could and should be richer, more expressive, and more enabling. Capabilities that could and should be added include annotation, precise linking, bidirectional linking, transclusion, dynamic views, dynamic linking, trails, orientation, integration of linking and style, and chunking. These capabilities are especially important to readers as opposed to authors. They have been implemented and proven in multiple systems, and some have been tried on a small scale on the Web; but they presently depend on individual sites' sufferance and sophistication. For basic functionality like this, we need to do better. A feature that only works with certain sites, plug-ins, or conventions; or only for sophisticated authors rather than for all authors and readers — makes “readers” (all of us at most times) second-class citizens in the world of information. We must rid ourselves of the notion that a reader is of a different class than an author: that the Web is largely a broadcast system that requires expertise to contribute beyond the occasional comment or re-post. Readers must become first-class citizens on The Web.