xml-dev - Re: Reserved names and documentation

[Marcus Carr <mrc@allette.com.au>]

Bryan Cooper wrote:

> <EVENT namespace='new'>
> <all tags in new namespace use DTD from the new namespace>
> </EVENT>
>
> This is a push namespace event.  enclosed <EVENTs>  can push other
> additional namespaces, and the parser would know to switch DTDs
> and pop off at each </EVENT>.

One problem would be that you lose context when you start parsing the fragments. For
example, what if you just have a number of section-like elements in an event? How do
you determine what the DOCTYPE element is, or whether they're occurring legally? The
processor may not even be able to determine at what point of the DTD it should be
initiating at.

Even if you were able to pass this information to the processor, compound documents
often aren't comprised of whole elements - for example, if you refer to legislation,
you might just want two clauses to appear, though the parent element might be an
entire Act. The only two ways that come quickly to mind would involve either padding
the two clauses to make it look like an Act, or invoke a separate <EVENT> for each
clause - an expensive workaround to avoid describing the structure more correctly. The
truly inventive evil genius might even invoke a new event for every element,
circumventing the requirement to adhere to that pesky DTD... if the elements
originated from the same DTD, would you bother nesting them, or just put them in
linearly?

> The idea is we need to send namespace <EVENT> to
> the parser so it can switch between multiple DTDs.  I don't
> think combining DTDs is necessary or even desirable.

I don't know of anyone who would say that combining DTDs is desirable, but I do think
it's necessary. The distinct lack of support for SUBDOC in SGML is strong evidence
that the suspend-repurpose-resume approach is difficult for application designers and
users alike. Imagine working in a word processor-like XML editor - can't put a
<ModelNo> element here? No problem, just start a new DOCTYPE. It's difficult enough to
create a single DTD that discourages this approach, let alone compounding the problem
by allowing multiple DOCTYPEs without providing satisfactory control over their
occurrence.

> Also, a new keyword like <EVENT> opens the door for some other
> parser directed possibilities.

That's a door I'll stay on this side of for the time being, thanks very much. :-)

> Tell me if this makes any sense at all....just trying to help...

My guess would be that the approach you describe would have been discussed by the WG
and rejected for some of the reasons above, but of course we're still looking for the
the DTD compounder...


--
Regards,

Marcus Carr                      email:  mrc@allette.com.au
___________________________________________________________________
Allette Systems (Australia)      www:    http://www.allette.com.au
___________________________________________________________________
"Everything should be made as simple as possible, but not simpler."
       - Einstein



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)