Re: XHTML 2.0: Where Is It Going? (PR#570)


Thank you for your long and thoughtful message. I think we agree, and that
your analysis is built on a misreading of the WG roadmap.

> For a start, this has been the "current" status of XHTML 2.0 over a
> year, as far as I can remember.

This is of course good news: we are still trying to achieve the same things
as we were a year ago!

> Are we ever going to see materials
> pertaining to XHTML 2.0, or are the Working Group still actively
> engaged in debating the relative merits of XHTML 1.0/Basic/1.1/m12n? I
> thought those were recommendations now?

Well, it is not as simple as you seem to think. The working group recently
produced three recommendations in six months! That is major productivity for
a W3C Working Group, because a lot of work goes into a recommendation!

We have a very systematic way of working, which is aided by our choice of
using modularisation, because we can subdivide the task into smaller tasks,
and combine the totality at the end in one fell swoop. So *everything* you
see from us is a step in the route of producing XHTML 2.0.

Take for instance the XML Events draft which we have been working on.
(, about to be replaced by a newer better
version that has gone through several iterations since the last public
version; members of W3C can see it already on the HTML WG home page) This
replaces the hard-wired events (which you complain about below) of HTML and
the current versions of XHTML.

Take for instance Modularisation in Schemas
( with a new version in the works).
This is an essential ingredient for defining XHTML 2.0.

And of course, don't forget XForms, which turned out to be such a big task
that a new Working Group got spun off, though with overlap with the HTML WG
( with a new version waiting in the wings).

So it might seem like nothing is happening, because nothing with the name
"XHTML 2.0" has yet appeared, but in fact immense amounts of work are being
expended on XHTML 2.0!

The XHTML 2.0 recommendation will be a tiny document, just like XHTML 1.1
is, pointing to a bunch of other documents that will already have appeared.

> The main problem, as the subject of this email hints at, is that the
> target market for future versions of XHTML 2.0 are rarely discussed by
> the W3C, and I think it would be a good idea to do so before it's "too
> late".

Actually there is much discussion on this very point. At least I seem to be
constantly busy with it...

> If (as the roadmap infers) XHTML 2.0 is just a redrafting of XHTML to
> make it "pure XML", I think that would be a mistake. People are *not*
> going to author XHTML 2.0 if they want it to display on all browsers,
> because only a couple of the latest ones support XML technologies to
> any usable degree. Backwards compatability is everything, and Web
> users are generally very conservative (with a small "c"). We shall be
> seeing V4 browsers for a while longer, and browsers such as Lynx and
> IE3 which have no capacity for the XML range of technologies
> "semantics".

Here we apparently have to disagree. The HTML WG is busy with the future. If
we had been interested only with what current browsers can do, we wouldn't
have tried even for HTML 4. HTML 4 was first a recommendation in December
1997, but it has only really been this year that you could start seriously
coding to it, as the HTML 4 browsers started to come online.

So backwards compatibility is not everything. XHTML 2.0 will be truly XML.
People who want to author to old browsers have got quite enough to be
getting on with, with the early versions of XHTML, until proper XML browsers
come on line.

> If the HTML WG were to pursue this line for XHTML 2.0, I
> would be shocked.

Prepare to be shocked. Actually, many people don't seem to appreciate what
an advantage XML is going to offer. Its built-in expandibility and
modularity are truly useful, and the generic tools that are now coming
onstream start making the dream of a semantic web more of a reality. One you
start to use the stuff, the benefits start becoming obvious.

> There is an alternative route that XHTML 2.0 could take, one that has
> been backed up with conversations that I've had with various people.
> It is clear from the development community that people are resorting
> to server side XML databases, and then transforming them using XSLT on
> the fly for output. Hopefully, this method of delivery can be
> intertwingled with the CC/PP and other profiling technologies that the
> W3C are developing. What this points to is that XHTML 2.0 should be a
> semantically rich language that can be transformed into other formats.
> Including XHTML 1.0 etc.!

The advantage of XHTML 2.0 is that you can choose either route and it will

> XHTML 2.0 should be something that will introduce pardigm shifts in
> the way that people think about User Interface technologies. Jason
> White put it excellently on the (public) wai-tech-comments list:-
> [[[
> I recognize, of course, that HTML can hardly capture the richness and
> variability, both structurally and semantically, of the myriad
> document types which are made available via the web. All that can be
> achieved in the core of XHTML, is to provide markup conventions that
> are likely to be used frequently across a variety of document types,
> leaving it to the extension mechanism to permit the definition of more
> specific and semantically precise constructs as the occasion demands.
> Thus, one needs to be very careful in deciding which structures merit
> inclusion in the predefined XHTML 2.0 modules, and in determining
> which semantic distinctions genuinely need to be preserved, such that
> the structures under consideration can not be adequately represented
> by more generic elements.
> ]]] -

Well... exactly! Our aim in producing XHTML is to fix the mistakes in HTML,
so that the errors of the past are not reproduced, and let the extension
mechanism do its stuff.

> It is very difficult to develop an XML language that is accessible and
> interoperable, and doubly so if it is based upon XHTML 1.0/1.1/m12n.,
> because they are so inherently awful, it's difficult to break out of
> the pattern.

You're beginning to contradict what you said in the beginning, and sound
more and more like an HTML WG member :-) "Built upon XHTML 1.0/etc" means:
you will still recognize it as XHTML; it does not mean that we are going to
let ourselves be restricted in what we do by requirements of backwards
compatibility. Maybe this is the source of the misunderstanding.

> The XML Accessibility Guidelines [1] under development by the WAI
> Protocols and Formats Working Group contain an excellent set of
> axioms, and comments that can guide people when defining new XML
> languages such as XHTML 2.0. AFAICT, XHTML 1.0 is in violation of 11
> guidelines:-

Tell me about it! WAI is one of the groups we talk to the most in fact, and
we have a very productive relationship with them. Fixing WAI errors was not
an aim of XHTML 1.0 by the way, but is most certainly an aim of XHTML 2.0.

[Analysis of XHTML 1.0 Accessibility Guideline violations snipped]

We have done a similar analysis in collaboration with the WAI group, with
similar though not identical conclusions.

> That's a lot of accessibility problems that need to be addressed, and
> I can't help thinking that if (as the XHTML roadmap implies) XHTML 2.0
> is built on top of XHTML 1.0 et al., these accessibility problems will
> be carried over.

See above. No backward compatibility.

> People want benefits, and new technologies have to have lots of
> benefits before people with give up their old ways. No matter what
> happens, XHTML 2.0 is going to have a slim target market.

Not sure if I agree. The advantages of the new forms will be enough to
satisfy very many people. Gregg Vanderheiden (one of the editors of the WAI
guidelines) gave the keynote at the CHI conference this year, and he pointed
out that more accessibility means more usability for everyone, and as
Forrester Research have discovered in their research, usability is the 2nd
most important property of a website (content is the 1st).

> The aim is to make it as usable as possible.

You're preaching to the choir here, though I would replace "The" with "An".

> The only benefit that generic XML
> content languages offer over generic SGML content languages is their
> transformability using XSLT, and to a limited extent, styling using
> CSS (implementations of this are buggy).

You forgot extensibility.

> In summary, if XHTML 2.0 is a dismal failure (no matter what route is
> taken), then we should not be surprised.

Actually I have been more than pleasantly surprised with the success of
XHTML 1.0 and family. Within 3 months of the XHTML spec we had two phones
implementing it!

> but people are only interested in what they see as immediate
> benefits, and "accessibility and interoperability" aren't usually seen
> as being something that people can benefit from.

Which is why the HTML WG is populated with people with vision and not with
people in search of immediate benefits!

Best wishes,

Steven Pemberton
Chair, W3C HTML WG

Received on Thursday, 16 August 2001 16:56:22 UTC