Requirements, requirements, requirements
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.
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.
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.
Many communities have a strong commitment to the HTML family.
Accessibility, Internationalisation, Device independence, Ubiquity, Browser manufacturers, Usability, ...
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.
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