Re: DTD Fragments and XML

Eve L. Maler wrote:
> It's hard to add a line to your internal subset that says this?
> 
> <!ENTITY % local.list.class "| MyList">

No, the difficulty is with becoming intimately familiar with the DTD you
want to extend and with its "architecture". If this kind of extension is
something that most apps are going to want to do, then it should just be
in SGML. 
 
> > * include content in some form of namespace.

> Not sure what this means.
 
When you include parts of one DTD in another you should be able to keep
the namespaces separate.
 
> One of the messier problems with this is managing recursive dependencies;
> for example, table cells eventually have to contain some of the contents
> that the rest of your DTD allows, like paragraphs or whatever.  But with
> the right kind of parameterization, this is done all the time today in SGML.

Right. I do it. I consider it a kind of voodoo that I don't think that
typical authors will put up with. I suspect that they will just delete
the DOCTYPE.
 
> The existing XML comes pretty close to the requirements you've stated.  The
> burden is on the original DTD (or DTD fragment) designer to parameterize
> the markup model properly; the user needs to know a couple of tricks in
> order to customize the DTD(s), but can come out the other side with a quite
> usable DTD that they can validate against.  

I'm guessing that authors will only learn the one "trick" of deleting
DOCTYPEs. At this point it is irrelevant whether I am right or wrong,
though. Everyone agrees that we need a way to declare namespaces in
well-formed documents. That was my real point. 

But I do think that at some point SGML should have extension mechanisms
that
are not reliant on a black box of parameter entity wizardy benignly
wielded
by forward-thinking DTD designers.

 Paul Prescod

Received on Wednesday, 21 May 1997 22:20:07 UTC