XMHTML Basic

It is unclear from reading this document
( http://www.w3.org/TR/1999/WD-xhtml-basic-19991221 ) what the goals of
defining XHTML Basic are.  It sounds like you are trying to make the
following argument:

The world of non-PC, user oriented devices accessing web content today is
fragmented.  There's WML, CHTML, Web-clipping, etc.  This is bad.  Instead,
lets define a single common subset of minimal features, so that people can
build extensions to this common subset.  This is better.

I don't understand how that solves anybody's problem.  We will end up with
just as many (if not more, now that it's official policy) "proprietary"
XHTML Basic extensions, which is an absolute nightmare for any content
provider, or content provider provider like myself.  What this means is
that in order to reach this growing number of different devices, our
flagship server, Lotus Domino, would have to support an ever growing number
of different XHTML Basic variants.  Claiming that we could just use
stylesheets is a cop out, because there is no standard way to associate a
stylesheet with a particular device at this time.  Furthermore, it remains
computationally expensive to custom generate content for every different
device that hits the server using stylesheets.

I am particularly confused by the inherent contradictions in the document.
For example, the last sentence of the first paragraph of the Abstract
states:

"It is designed for Web clients that do not support the full set of XHTML
features; for example, Web clients such as mobile phones, PDAs, pagers and
settop boxes."

Section 1.3.7 then uses the lack of a pointing device as justification for
excluding image-maps.  Yet the most popular PDA in the world, the Palm
Connected Organizer, features a highly successful pointing device called a
stylus.  Now, if I understand this correctly, somebody else (Palm?) would
now have to specify an XHTML Basic extension (XHTML Palm?) that supports
image maps.  Which means that Domino cannot generate XHTML Basic, and
expect to have a good user experience on a Palm.  Instead, we have to
support XHTML Palm, XHTML WinCE, etc, etc.

Section 1.3.2 avoids the issue of events altogether.  Yet, the most popular
markup language for mobile phones, WML, has an event handling mechanism.
So again, WML 2.0? becomes XHTML Phone or something like that.  Yet another
language for Domino to support.  Similarly, I would imagine that a good
XHTML for Palm implementation would support a "pendown" event of some kind
(or at least overload the "mousedown" event).  So we would end up with a
different event model for XHTML Palm.

I am not opposed to the idea of modularization of XHTML, but defining XHTML
Basic and leaving the rest up to chance is imho a bad idea.  I would favor
an approach that at least attempted to standardize XHTML basic modules for
different device classes such as a PDA versus a basic phone, versus a
"smart" phone, versus a pager, etc.  I don't harbor any fantasies that we
can have a single XHTML module that satisfies the requirements of all the
different devices listed above.  But if we can at least standardize it to
the level of a device class, rather than a device instance, I would breathe
a lot easier.  As it stands, Palm and Microsoft will feel free to define
completely incompatible extensions of XHTML for devices that are
effectively identical.  The same goes for phone manufacturers, with the
possible mitigation of the existence of the WAP forum.  The specification
of XHTML Basic completely ignores the problem of managing this
proliferation of XHTML Basic extensions, and I think that is a mistake.  I
would like to see at least the following standard extensions of XHTML Basic
defined:

XHTML Basic PDA - Includes image maps, buttons, pen and other events,
scripts, and stylesheets.
XHTML Basic Phone - Includes an event module (preferably the same as the
PDA event module or at least similar!), variables, etc. (WML next).
XHTML Basic Pager - Includes a simple event module, variables, etc.
...
other device types?
...

Smartphones would use XHTML Basic PDA with some phone specific extensions
if necessary.  Again, our goal should be to limit the number of different
content languages in use at any given time, not to encourage the
proliferation of new languages!  By proliferating content languages we
seriously impede the ability of the content provider to reach the largest
possible audience, and we similarly impede the tools providers in
effectively serving the content providers.

Quinton Zondervan
qyz@lotus.com
Software Architect
Lotus Mobile Communications Group

Received on Monday, 10 January 2000 14:20:43 UTC