Re: B.7 Conditional inclusion in DTDs?

On Tue, 15 Oct 1996 09:52:51 -0400 Eve L. Maler said:
>At 07:14 PM 10/14/96 -0500, Len Bullard wrote:
>>Charles F. Goldfarb wrote:
>>> XML shouldn't have conditional DTDs. They defeat the objective of
>>> simplicity.
>>> Those who need complex DTD management will be using full SGML and
>>> can easily generate XML from it.
>>Also concur.
>
>As do I (I think).  Presenting DTDs to new XML users will be easier if
>we constrain them (the DTDs :-) to single "state spaces" for now.

I dissent strongly.  XML should be as simple as possible, but not
simpler.

If multi-flavored DTDs are not allowed in XML, it ceases to be even
potentially a read-edit-write language suitable for work with documents,
and becomes exclusively a write-only language for publication.  Not much
reason to support the desperate Perl hacker in XML if XML is just for
publication:  the DPH will in general be working on the working copies
of documents, not documents that have already been through an
irreversible publication process.

If publication were all that were needed, we could have been happy just
all encouraging SoftQuad to release Panorama for other platforms.  We
need -- Dave Hollander has been particularly eloquent on this score -- a
language suitable both for publication and for maintenance.

Eliminating conditional inclusion in DTDs defeats the objective of XML
as a strong, powerful language for work with texts, and abandons without
necessity the goal of having XML possess expressive power approximately
equal to that of Full SGML.

When we are talking about a formalism not powerful enough to represent
the DTD for HTML 2.0, I think we are talking about too weak a formalism.

Production DTDs require parse-time customization.  XML requires
the power to handle production DTDs.  Ergo, XML requires parse-time
customization -- i.e. condition inclusion in DTDs.

-C. M. Sperberg-McQueen

Received on Tuesday, 15 October 1996 18:28:07 UTC