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

Hi,

Firstly, many thanks for taking the time out to formulate a well-thought
out reply to my message. I agree with the majority of points that you have
raised, but as ever, the details are highly important, and I have a number
of comments.

[...]
> 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!

Yes, and work well done, credit where credit's due, et cetera.

[...]
> 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.

Tiny: really? I hope we won't have to rely on old HTML 4.01 definitions for
the elements, some of which are inadequate, and almost all of which should
be updated. If XHTML 2.0 has anywhere near the same kind of *coverage* as
HTML 4.01 (although not necessarily the same set of elements), then I'd
expect it to be as long, perhaps longer. It is rather strange having to
cite HTML 4.01 normatively for 1.1/m12n as it is, without having to do it
for 2.0 as well!

But I know what you mean about the XHTML 2.0 draft being a hub for many
existing technologies: that's a good sign, because it indicates that XHTML
2.0 will avoid reinventing the wheel, which is an architectural axiom that
is often very difficult to follow.

[...]
> 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.

Well, almost any instance of HTML 4.01 could at least partially display on
browsers going back years; I would expect that XHTML 2.0 won't display on
any, except perhaps Netscape6, which seems to have partial XLink support
etc. What I meant is that people aren't going to be authoring XHTML 2.0 to
display natively on browsers. I simply don't think that people are going to
issue a technology that only displays on browsers which have a small
percentage of the browser market, even if that said technology is
architecturally clean. Not for a long time, anyway.

But I am not *asking* for backwards compatability with any user agents. On
the contrary, I am happy that the WG (from your comments) appear to be as
impartial to the lengths that current browsers implement XML at all. But if
parts of the language are twisted to display on a certain browser... then
that doesn't reflect well on the whole evolution of XHTML 2.0 as a whole.

> 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.

Only certain features: basic subsets of HTML 4.01 should display on
practically any browser.

[...]
> 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.

I take this as fact that XHTML 2.0 will a) not be warped to fit in with
current browser implementations, and b) the scope of its deployment will
not include the casual Website provider? So, what is the scope?

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

I'm not shocked; actually I'm rather pleased. The "line" that I referred to
was backwards compatability of some degree. Hmm... my original note was
badly phrased:-

[[[
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.
]]]

I meant that if 2.0 is a redrafting as "pure XML" *and* the scope of its
deployment is the casual developer, then that would be an obvious mistake
because I don't expect browsers to handle "pure XML" for a while to come. E
ven if they do, there will be people missing out because they (for some
reason, perhaps out of their control) cannot upgrade their browsers. Now, I
am not a luddite; I rant at people when they say a page breaks in a 4.x
version of Netscape, and I really dislike HTML in its current state. But
realistically, people are very conservative, and that has to be accounted
for.

Server-side XML transformed into current technologies is certainly the way
to go, in my opinion. I would also expect XHTML 2.0 to not contain any
mechanism more complicated than a HyperText link, including forms and
tables. As far as my own personal experiments with device independence have
gone, it's very difficult to agree on a lowest common denominator, and so
often the best policy is the draw the line much lower than is theoretically
necessary. The great thing is that XHTML 2.0 is going to be a HyperText
language... *the* HyperText language, as far as the W3C are concerned.
Complex objects can be referenced with a HyperText link, perhaps as an
object, or whatever. I can envisage the modular technologies such as XForms
etc. that 2.0 is built around having distinct MIME types, and hence being
referencable from 2.0 by link only - perhaps from a <switch>-like element
that allows people to choose between forms technologies etc. (I presume
here that some range of XForms cannot be transformed back into XHTML Basic
forms).

I realise that's "mildly extremist", if that isn't an oxymoron, but I think
it's the direction in which generic content language must be taken if they
are to remain interoperable.

> 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.

Woah there a second! Perhaps my definition of a "Semantic Web" is different
from many, but I don't feel that documentation is something that a machine
should be expected to grok, no matter how in tune with XML it is. I don't
think that adding XLink and XForms and whatever else to XHTML 2.0 will make
it become a language fit for the Semantic Web: even screen scraping will
probably be difficult, because I have a feeling that the metadata
mechanisms will be screwy (how can they not be?). Semantic Web formats are
RDF, perhaps XTM, and so on: pure XML data formats that use URIs to
represent the resources in question.

Metadata for XHTML 2.0 is going to be one of my primary interests as it
develops, considering my healthy obsession with RDF and the Semantic Web. I
sincerely hope that people don't start embedding unscoped RDF in XHTML.

[...]
> The advantage of XHTML 2.0 is that you can choose either
> route and it will work.

(The "either route" referring to renderability and transformability) - good
luck.

[...]
> 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.

I hope so. We're all aware of how pitiful HTML currently is, and I think
it's a big step from there to an architecturally sound language. There are
many factors to be considered: what really constitutes a "list" rather than
a "group" or "division"? Are these purely related to display/rendering, or
do they have other inherent semantics? Then there's the stuff about
metadata: how can you discourage people from adding unscoped metadata to
XHTML 2.0 for no reason? Extensibility of inline phrasing, and the harmful
aspect of classes are other topics that deserve a mention: will classes in
XHTML 2.0 be QName lists, of NMTOKENS? Are the HTML WG aware of the abuse
that can be prevalent with NMTOKENS class attribute values? There are
hundreds of such things to consider, and it is my hope that by the time 2.0
goes to recommendation, they will all be resolved to some degree of
satisfaction.

> > 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 :-)

My phrasing is just terrible (I'm quite ashamed of myself, really).

We're all working towards a common goal here: a clean and implementable
generic HyperMedia content language. Personally, languages that violate
even the smallest of architectural design "rules" make me feel queasy. You
can imagine how HTML feels, and why I am a) so looking forward to XHTML
2.0, and b) so anxious about the development thereof. I just want a decent
language to implement on a daily basis, and I don't feel that I'm going to
get it (even with xWebL/XNote).

[...]
> WAI is one of the groups we talk to the most in fact, and
> we have a very productive relationship with them.

Yep, I noticed.

> Fixing WAI errors was not an aim of XHTML 1.0 by the way,

I realise that.

> but is most certainly an aim of XHTML 2.0.

Phew.

> [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.

I presume you're talking about wai-tech-comments? That's a publically
archived list, BTW. If so, note that the XML Accessibility Guidelines were
in a very early stage of development, and that PF are always actively
engaged in many, many, many things.

> > No matter what happens, XHTML 2.0 is going to have a
> > slim target market.
>
> Not sure if I agree.

May I ask how many people you expect to take on XHTML 2.0? In terms of how
many people are currently implementing XHTML 1.0 etc., a year and a half
after recommendation. XHTML has most certainly had its critics. It doesn't
have any major advantages over HTML to a huge percentage of developers
(although it had major impact for myself, w.r.t. transformability). My
personal, and very simple, aim is to write my homepage in XHTML 2.0 and be
satisfied with it. That's just my own (incedental) XHTML 2.0 success
criterion :-)

But just because it has a slim target market doesn't mean that it won't
rate as a "successful" language, or whatever. Indeed, I'm predicting that
for XHTML 2.0 to be a good language, it has to be a language with a slim
target market. On the other hand, you have HTML tag soup from 1990-present,
and there are billions of HTML documents... but HTML is a pile of rubbish,
architecturally.

[...]
> > The aim is to make it as usable as possible.
>
> You're preaching to the choir here, though I would replace
> "The" with "An".

Agreed.

> > 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.

I left out syntactic extensibility (oops), which of course reached a peak
with Murray's m12n, but semantic extensibility isn't really possible.

> > 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!

I won't be impressed until I see XHTML pages displaying on fridges and
toilets. Seriously though, 1.0 has gone quite well, but then it renders in
(99%) of current browsers...

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

For the sake of the future of the Web, its users, and its developers, I
hope so.

P.S. Can't we cut w3c-html-wg from the CC list, seeing as how threads like
these tend to generate a lot of light/heat, and that all of the HTML WG
members whould be subscribed to www-html anyway according to the HTML WG
charter?

--
Kindest Regards,
Sean B. Palmer
@prefix : <http://webns.net/roughterms/> .
:Sean :hasHomepage <http://purl.org/net/sbp/> .

Received on Friday, 17 August 2001 16:19:54 UTC