HTML/XML Task Force Report HTML/XML Task Force Report W3C Working Group Note 9 February 2012 This Version: http://www.w3.org/TR/2012/NOTE-html-xml-tf-report-20120209/ Latest Version: http://www.w3.org/TR/html-xml-tf-report/ Editor: Norman Walsh MarkLogic Corporation < [email protected] This document is also available in these non-normative formats: XML Copyright W3C ® MIT ERCIM Keio liability trademark document use Abstract This document is the report of the TAG Task Force established to explore how interoperability between HTML and XML could be improved. It describes several use cases that the Task Force considered relevant and proposed resolutions to those cases. Status of this Document This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index This Note is a report from an XML/HTML task force at the request Technical Architecture Group [email protected] archives [email protected] archives Publication as a Working Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. This document was produced by a group operating under the 5 February 2004 W3C Patent Policy public list of any patent disclosures Essential Claim(s) section 6 of the W3C Patent Policy Table of Contents 1 Introduction 1.1 Terminology 2 Use Cases 2.1 How can an XML toolchain be used to consume HTML? 2.1.1 Problem statement 2.1.2 Resolution 2.2 How can an HTML toolchain be used to consume XML? 2.2.1 Problem statement 2.2.2 Resolution 2.3 How can islands of HTML be embedded in XML? 2.3.1 Problem statement 2.3.2 Resolution 2.4 How can islands of XML be embedded in HTML? 2.4.1 Problem statement 2.4.2 Resolution 2.5 How can XML be made more forgiving of errors? 2.5.1 Problem statement 2.5.2 Resolution 3 Conclusions A References B Contributors HTML and XML share a common ancestor in SGML. The precise details of that ancestry are not strictly important, its significant consequence is that HTML and XML have a quite similar surface syntax. Both use angle brackets and ampersands to distinguish “markup” characters from “content” characters. Both have elements which contain other content and elements which are empty. This high level of surface similarity suggests, at least to some and at least at first, that there should be a high level of interoperability between HTML and XML systems. This notion is amplified by the fact that when XML arrived on the scene, well after HTML was widely deployed, efforts were made to recast HTML as an XML application rather than an SGML application. HTML was never broadly implemented as an “SGML application”, but it was defined as one in the early HTML specifications. However, if you look beyond those high-level generalities, the languages are quite different and serve quite different purposes. Where HTML is a single language, XML is a framework for defining languages. Where HTML defines how a tree is constructed from any input, XML only defines tree construction for a small subset of all possible inputs. Where HTML defines explicit extension points within a single vocabulary, XML encourages the use of multiple vocabularies defined in a distributed fashion. Where HTML is in a small, explicit set of namespaces, XML provides for an unbounded number of namespaces. Against the backdrop of this tension, the TAG formed this Task Force in order to explore how interoperability between HTML and XML could be improved. The Task Force worked in public; an archive of its deliberations is preserved In the following section, we'll describe a set of use cases that the Task Force considered, and how the needs of those use cases can be met today. Additional notes and other background material for many of these use cases is available in the wiki A few notes about about terminology: In general, we refer the family of documents that are colloquially understood to be HTML (HTML, XHTML, HTML5) using the term “HTML”. In those cases where we want to draw attention to XHTML or HTML5 specifically, we use the more specific terms. There are a great many ways to represent the “object model” of an HTML or XML document. There are specifications for both abstract and concrete representations. As a simplification, we use the term “DOM” (Document Object Model) throughout as a general term for any of these possible representations. An “HTML parser” is one that consumes HTML markup and produces a DOM. We use the term “HTML5 parser” in those cases where we wish to draw attention explicitly to the parsing behaviors described by [ HTML5 The task force set out to examine a number of use cases Problem statement Resolution The Task Force found two approaches to address this problem: use polyglot markup or introduce an HTML parser into your processing toolchain. Polyglot markup However, the vast majority of HTML documents could Where it is applicable, polyglot markup constrains the text/html Alternatively, rather than attempting to constrain the HTML input so that it conforms to the polyglot constraints, an HTML parser can be introduced to the front of the XML toolchain. Such a parser reads the HTML markup “as she is writ” in the world at large and produces a representation of that tree that an XML processor can use. It is still possible Like XML parsing, HTML parsing produces a tree. Exposing that tree to the XML toolchain (as a sequence of events, such as SAX events, or an in-memory tree model, or through any other appropriate implementation mechanism) makes all of the XML power available to any HTML document. Problem statement (If the XML in question is entirely XHTML or XHTML with only SVG and MathML embedded, then the differences are likely to be small and the HTML toolchain is likely to do the right thing; the focus of this use case is on XML vocabularies that are not in the HTML family.) Resolution For XML content that needs to be textually embedded in HTML5, the most successful approach may be to simply translate the XML to HTML5 before passing it to the HTML5 tool. A wide variety of XML tools exist to simplify the technical challenge of transforming XML; of course, the semantic challenge of translating an arbitrary XML vocabulary into HTML5 may be very difficult. If a faithful translation isn't possible, even the simple transformation that strips out processing instructions and non-HTML namespaces may help. Processing a real XML document with an HTML5 parser is probably never going to be possible with complete fidelity. In an environment where the HTML toolchain includes access to an XML parser and the HTML and XML resources can be managed separately, the most successful approach is likely to involve parsing the XML with an XML parser and the HTML with an HTML parser. Problem statement not This pattern establishes the practice of embedding islands of HTML in XML documents that are not otherwise anything like HTML or intended to be processed directly by HTML tools. The question naturally arises, how can HTML5 be embedded in an XML document? Resolution Make sure that the HTML markup is well-formed XML. This is typically done by explicitly or implicitly asserting that the content is XHTML. This makes the HTML a natural part of the XML document at the expense of imposing XML markup requirements on the author. Within the container element, escape all characters that might be interpreted as markup. This absolves the author of the responsibility to construct well-formed XML, at the expense of requiring tools to escape and unescape the markup and support non-well-formed markup “downstream”. Both of these techniques can be applied to HTML5 markup. In the former case, use the XML serialization of HTML5. In the latter case, escape the HTML5 markup. If the HTML subsystem has an interface that allows document trees to be passed to it, the XHTML subtree should be extracted from the larger XML tree and passed to the HTML subsystem. If the HTML subsystem only accepts HTML source text as its input, the XHTML subtree needs to be serialized as HTML and passed to the HTML subsystem for parsing using an HTML parser. In the latter case, some non-conforming constructs may not round-trip to the same tree shape when serialized as HTML and reparsed as HTML. Also, conforming trees that have tr table tr tbody table Problem statement The user's expectation is that these XML islands will appear in the DOM where they can be addressed with JavaScript and formatted with CSS. Resolution text/html The practical result is that a “naked” XML island in an HTML5 document will not reliably produce anything that resembles the DOM one would expect from casual inspection of the XML island. In order to conceal the XML markup from an HTML5 parser's attempts to correct errors, the XML must be stored within a script application/xml What an HTML5 parser produces when it processes this script element is a script This technique allows arbitrary XML islands to be embedded in HTML5, but such islands are only accessible to processors that are able and willing to execute the necessary JavaScript shim. Note: XHTML content served as application/xhtml+xml Problem statement An XML parser is utterly unforgiving in the face of even small markup errors. As a result, XML constructed using otherwise straightforward techniques in many programming languages is sometimes not well-formed unless great care is taken. Resolution The Task Force considered several areas of interoperability that arose in these use cases: consuming HTML with XML tools, consuming XML with HTML tools, and embedding islands of one within the other. As described above, there are well understood boundaries within which any solution to each use case can operate. And within those boundaries, there exists today a solution that, while perhaps not wholly satisfactory, sits within those boundaries. No wholly satisfying solution appears possible within the accepted constraints; it would appear that we have already achieved the practical solutions. With respect to the question of making XML more forgiving to errors, it's clear that some work has been done in this area and that it is possible to articulate coherent proposals for such change. We recommend further study within the XML community before determining how best to explore these changes. On the question of Polyglot markup, there seems to be little consensus. One line of argument suggests that, to the extent that it is practical to obey the Robustness principle [ XML5 XML5 [ Polyglot Polyglot Markup: HTML-Compatible XHTML Documents [ HTML5 HTML5: A vocabulary and associated APIs for HTML and XHTML [ XHTML XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition) The Task Force is indebted to the contributors on the public mailing list, the wiki, and those individuals who participated in teleconferences and meetings. In particular, the following individuals devoted time and energy to the construction of this document: Robin Berjon David Carlisle Michael Champion John Cowan Anne van Kesteren Noah Mendelsohn Henri Sivonen Norman Walsh