Re: XML and required DTDs

At 07:48 PM 9/13/96 -0700, Tim Bray wrote:
> o I believe that there are many things you can do with structured
>   text that do not require Full Markup Declaration (search, display, 
>   analyze).  We want you to be able to do those things in XML without
>   having a Full Markup Declaration at hand.

I agree wholeheartedly with #4 of the design principles especially with
the examples that Tim provided above. The problem seems to arise at the
definition of "useful" in the design principles:

     In particular, it shall be straightforwardly possible to construct
     useful XML applications which do not read, or need to read, the DTD
     of the XML document.

Search engines may never be able to find a DTD if they're indexing docs
retrieved from the net, some browsers can already do a pretty good job
of presenting a doc without a DTD (DynaText, for example), and there are
any number of applications that can perform a lot of "useful" processing
without a DTD.

There are also a lot of applications where given a relatively simple
doctype, a DTD may never be necessary. A specialty doctype and a
chunk of java client-side can take a lot of pressure off of a gateway
(to a DBMS) server. If you've ever had a key gateway crash because its
process table filled up you understand how valuable this can be.

I also agree that it might be desirable to express the DTD using the
same syntax as the doc. This would eliminate the need for a completely
separate parsing module. Kimber posted a good start to c.t.s a year or
two ago, Wayne's encapsulated the productions making it pretty verbose
but another option, ours is built to encapsulate the documentation with
the declarations so wouldn't really apply, Michael? Yours?

However, when we start talking about partial DTDs or XML editors that
don't use a DTD, my hackles go up. First, I suggest killing the idea
of a partial DTD. If any of the declarations are required, just send
the whole DTD. I don't see any benefit in trying to extract a partial
DTD (who's going to do that anyway?). If it's an issue of syntax, then
let's change the syntax of the DTD. I care about the syntax of the
instances, I don't care if we use COBOL to express the DTD.

Unless we made it some incredibly verbose syntax, I don't think the size
of the DTD is an issue. I would bet that it will always be significantly
smaller than the stylesheet. I also believe that the vast majority of XML
applications will be inside corporate networks where the number of DTDs
will be relatively small and caching systems will eliminate most DTD
fetches anyway.

If it's syntax, let's address it. I think it would be time better spent
than trying to come up with partial DTD delivery schemes.


Robert Streich				streich@slb.com
Schlumberger				voice: 1 512 331 3318
Austin Research				fax:   1 512 331 3760