Re: More proposals -- and some critical implementation issues

dgd@cs.bu.edu (David G. Durand) wrote:

> [...]
> And, there is currently no way that we can
> tell whether an application has (or intends to fetch) the DTD for a
> document unless we add new DTD intention parameters to HTTP. In other
> words, if there is no DTD, we will have no default attribute values. We
> decided that this was OK for graphical rendering because we are assuming
> that the stylesheet can work without that explicit information. I propose
> that we follow the same strategy for linking. [...]
>
>    We may yet have to bite the bullet and allow stylesheets within
> documents: which is a very bad idea, I think. But I don't see how we can
> require DTDs for linking, and claim to have eliminated them from XML -- at
>                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> least in the web context, linking is a hard requirement.

It was not my impression that one of the goals of XML
was to eliminate DTDs altogether; I thought we were
only trying to enable "naked parsing".  "Naked processing"
is a different matter -- it seems pretty clear to me that
some applications are going to need to parse (at least part of)
the DTD in any case, e.g., in order to process external
entity references.

I don't see how parsing <!ATTLIST ...> declarations
is any harder than parsing "the stylesheet" -- depending
of course on what notation we end up using for "the
stylesheet", but if it's DSSSL I'd guess that implementors
would have an easier time with a DTD.  If bullet-biting
looks inevitable, I suggest that we should use SGML's
constructs for associating information with element types
(#FIXED attributes) over other, as-yet undefined solutions
(embedded stylesheets).


--Joe English

  jenglish@crl.com

Received on Thursday, 2 January 1997 13:17:36 UTC