XHTML and the W3C Architecture

How did we get here?

Requirements, requirements, requirements

1998: Workshop "Shaping the Future of HTML"

Results: create an XML version of HTML

It was agreed that further extending HTML 4.0 would be difficult, as would converting 4.0 to be an XML application. The proposed way to break free of these restrictions is to make a fresh start with the next generation of HTML based upon a suite of XML tag-sets. The workshop expressed a need for a better match to database and workflow applications, and for the widely disparate capabilities of small/mobile devices. Modularizing HTML will provide the flexibility needed for this.


The tag-sets will be developed in cooperation with experts from each area, with a clean rationale design for each tag-set and how these can be combined. The new version of HTML will be informed by 4.0 but not bound by it. There is no requirement for strict upwards compatibility, although the migration path will be carefully considered. New features and richer authoring environments will provide compelling reasons for upgrading to the next generation of HTML.

Browser and authoring tool support for existing versions of HTML will be with us for a long time to come. The new approach will make it easier to develop powerful new tools without the penalty of having to provide full backwards compatibility with existing content. Style sheets and scripts will make it practical to tune Web content to the profile of each device, with the flexibility to apply this at authoring time, in proxy servers or in the browser.

Resulting HTML WG charter mission

To fulfill the promise of XML for applying XHTML to a wide variety of platforms. To assist W3C's leadership role to support rich Web contents that combine XHTML with other W3C's work on areas such as math, scalable vector graphics, synchronized multimedia, and forms.

The W3C Architecture

Design and create a set of markups, based on a centrally agreed XML architecture

Markups will be designed by domain experts

Markups will be combinable into documents, using namespaces to identify the markup used.

Everyone feels they own HTML

Many communities have a strong commitment to the HTML family.

Accessibility, Internationalisation, Device independence, Ubiquity, Browser manufacturers, Usability, ...

Bi-modal community

Disaffection in parts of the community with XML and namespaces, which the HTML WG has often warned against.

Hard to work in such an environment. For instance:

Browser manufacturer: "No one wants XML Schemas"

→ Damned if you do, damned if you don't

The discussion is not really about HTML, but about XML.

Challenges for W3C

Protect the W3C Architecture

Work against disaffection of parties

Any design must be based on requirements input from all involved communities

Otherwise, we will end up with <blink> writ large, and spend the next decennium undoing the damage