ATTN: Please comment on XHTML (before it's too late)

roddey at roddey at
Tue Sep 7 23:47:21 BST 1999

>Adding three lines of code introduces the opportunity for three times
>the bugs in a real application? I don't buy it. Looking for "HTML 4.0
>strict" OR "HTML 4.0 frameset" is no harder than looking for "UL" OR
>"OL", if the software is set up right.
>And it is *just as necessary in the general case*. There will be tons of
>code that needs to work the same across "similar" element types across

I said this elsewhere, so this is a little redundant but...

I think its more complex than that. Its more than adding 3 lines of code. What
if you want to validate the XHTML? That requires that the validation mechanism
in all parsers now does partial URL matching? On which URLs does it do this? How
will parsers, which use decl pools in which uniquely identified elements are
given unique ids, deal with this?

Otherwise, you push off validation, attribute uniqueness checks, attribute
normalization, etc... off out of the parser which is what the parser was kind of
designed for in the first place, right?

If you think that those apps that need this functionality are happy to do it all
themselves, then I have no problem with that. But I think that it deserves
consideration that such documents could not meaningfully be dealt with by
parsers that exist now, other than as non-validated, non-namespace aware
documents pretty much. Is that really useful? And would we want to add all that
complexity to parsers in order to deal with this issue, if its not sufficient to
have the apps that need it handle all the issues?

Dean Roddey
Software Weenie
IBM Center for Java Technology - Silicon Valley
roddey at

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as: and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list