W3C home > Mailing lists > Public > www-html@w3.org > January 2000

Re: Why DOCTYPE Declarations for XHTML?

From: W. Eliot Kimber <eliot@isogen.com>
Date: Mon, 17 Jan 2000 17:05:14 -0500 (EST)
To: www-html@w3.org
Message-id: <3883921A.684F48F8@isogen.com>
Murray Altheim wrote:
> "W. Eliot Kimber" wrote:
> >
> > I appreciate what Murray is trying to do and I completely understand his
> > intent, but it is misguided and will only lead to pain. It is not
> > necessary for the XHTML user community to understand the subtlty of my
> > argument in order to use some mechanism other than DOCTYPE declarations.
> > It is only required that XHTML do the appropriate thing.
> Pain? What pain? We're doing the appropriate thing within the world of
> XML, as defined by the XML 1.0 Recommendation. Your suggestion would be
> inappropriate within this, and would be invisible to current XML parsers.
> The use of DOCTYPE is completely conformant with the XML 1.0 Recommendation.

The pain to which I refer is the pain resulting from the use of a
facility that only gives the illusion of doing what is really wanted,
such that things that people think are being said or enforced are not
being said and are not enforceable.

> > Why should XHTML require the the feature of SGML that XML correctly
> > worked so hard to eliminate (DOCTYPE declarations) when the use of it is
> > not reliable as a way to define types, for all the reasons I've stated
> > many times?
> Simple answer: there's not a conformant XML parser alive today that does
> anything other than use DOCTYPE to declare what document type definition
> a document conforms to, 

But that's exactly my point: DOCTYPE declarations *do not declare
types*. I don't know what part of *no* people don't get about this. 

                       and as you well know (being to my knowledge part
> of the reason you left the XML WG), the emperor doesn't like PIs. We've
> been told repeatedly to avoid use of PIs for anything fundamental.

I wasn't aware that Tim B-L's aversion was to PIs in general. So what?
Then take the namespace approach and use an attribute of the document
element to do the same thing. 

> Until we have an alternative endorsed by the W3C in a W3C specification we
> must continue to use the tried and true methods as defined in SGML and XML,
> ie., the tools we have. We can't even use XLink in our specs until it
> reaches Recommendation.

You do have an alternative: a namespace use declaration with a meaning
defined by the XHTML spec.
> I honestly don't know why you're arguing with me about this. 

I'm arguing with you about it because it's important. XHTML will set a
precedent, an important one, and it would be a tragedy if it sets the
wrong precedent. Pretending that DOCTYPE declarations have any value for
defining types is wrong and it shouldn't be done. It seems very clear to

Just because XML provides the optional feature of DOCTYPE declarations
doesn't mean that XHTML is obligated to require their use or impart any
special meaning to their use when there are other was to get what you
want which are reliable.

The SGML and XML standards define a universe in which you can only talk
about a single document. In that context, DOCTYPE declarations do define
types, types with exactly one instance. But that's not very useful. It
is perhaps the most serious failing of SGML (and by inheritance, XML)
that it does not provide a markup declaration for binding documents to
true type definitions. But it doesn't and we have to work around that.
But pretending that DOCTYPE declarations do something they don't is not
the right workaround.

I don't want to disrupt y'all's work, I was just responding to the issue
and the reference my earlier postings--I wanted to support Arjun in his
arguments because I feel at least as strongly about this now as I did
two years ago. I won't say any more--I've said everything I can say
about this as clearly as it's possible for me to say it. 


Received on Monday, 17 January 2000 17:07:31 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:52 UTC