Lists Home |
Date Index |
- From: David Brownell <email@example.com>
- To: xml <firstname.lastname@example.org>
- Date: Wed, 03 Nov 1999 23:43:13 -0800
WARNING: I may risk re-igniting the N-namespaces war by responding ...
> Curt Arnold sez:
> > Namespace free XHTML would be fine with me.
Although I certainly suggested that at one point, I think _one_ is the
preferable outcome, and the motivation for _zero_ namespaces would only
have been to get XHTML out quicker than it appears can now happen.
> Depends on what you mean by that; I see the dangerous potential there
> of descending into the same morass we currently have with HTML, where
> we theoretically go by the DTD,
I never thought that HTML <!DOCTYPE ...> declarations were ever
usable for any purpose other than content providers to validate, in
order to work on more browsers. How could they be? I think that
HotJava once tried to validate -- and gave up quickly because so
many sites _only_ produce illegal HTML.
> but in actuality, it's anybody's guess what browserisms a random
> user agent will support. Witness the spotty support CSS1 and CSS2 have,
> not to mention HTML4 itself.
Namespaces are for distinguishing an XHTML "table" from furniture, not
for nuancing IE4/Mac table browserisms (bugs) from NN4.61/Linux ones.
Nobody wants to see one namespace per "browserism", with a W3C precedent
in that space ... start with three "browserisms", and there will be
hundreds of different XHTML namespaces in no time at all. Nobody will
even bother to look at the namespaces if that's how it goes.
> should we expect that the UAs we will have for XML will do any better?
Better in what respect -- being less buggy? Two things come to mind:
- One is that so many developers understand the damage that comes from
HTML standards being so thoroughly ignored ... which wasn't widely
understood as the damage was being created. XML has "draconian"
error handling (no display if it's not well formed!), which is a
big step forward (though it only goes so far).
This means that users are already demanding (and getting) better
standards conformance. It doesn't come easy to many vendors since
an "Open" playing field doesn't provide customer lockin.
- Another is that now we're seeing more alternatives, including some
significant Open Source componentry (not just Mozilla).
This means that vendors in the XML space won't be able to get away
with as much. (Watch out for the tactics some will take to cope...
some bits of XML will get needlessly complex, as entry barriers for
the newer vendors and perhaps as homes for more "browserisms".)
Surely there are other reasons, too -- like not giving in to despair! ;-)
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)