Lists Home |
Date Index |
- From: Bryan Cooper <email@example.com>
- To: Tim Bray <firstname.lastname@example.org>, "Simon St.Laurent" <email@example.com>, <firstname.lastname@example.org>
- Date: Tue, 05 Jan 1999 18:33:03 -0800
I personally feel namespaces as defined will implicitly REQUIRE everyone to
explicitly tag each and every element which would be extra overhead
and reduce the readability of the XML files. It also does
not resolve your question about how to declare within
the "primary" or "current" DTD that these "secondary" tags are allowed/disallowed.
The problem appears to be that we have mixed, within the namespace
redefinition of existing <tag>, a parser switch
to another namespace while still parsing within the current namespace.
Ouch! I think in general XML is best at making things EXPLICIT
so this issue won't go away...
A more explicit parser command tag like
<all tags in new namespace use DTD from the new namespace>
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>.
For your problem, the primary DTD would only need to explicitly allow
<EVENT> commands within specified <TAGS>, but would not need to declare
anything within the <EVENT> since we are now in new namespace
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 think
that the DTD element containing secondary <TAGS> should then
explicitly allow <EVENT> tags as a new XML type to support
this kind of syntax. Once the <EVENT> occurs, we are in the
secondary DTD which does NOT have to allow namespace switching
Rather, I think that XML should have EVENTs that are clearly designed
for parser interaction and explicitly tagged inside the DTD.
The primary DTD could then in fact declare which new namespace
changes it allowed, or could allow any random namespace.
We seem to have implicit namespace <EVENT> already occuring according
to the namespace spec, I am just suggesting we make them
explicit as a way to handle your DTD concerns AND to avoid
everyone explicitly sticking namespace into every element.
Rather, they could explicitly change just the namespace WHILE
STILL PARSING WITHIN the primary/current namespace/DTD, and then let
the secondary DTD do its job with the next, incoming <TAG>.
The secondary DTD does not even need to KNOW that it is
within any namespace.
Also, a new keyword like <EVENT> opens the door for some other
parser directed possibilities.
Tell me if this makes any sense at all....just trying to help...
>Now, on to the difficult problem: how do you go about making that
>DTD I mentioned in step 1, that has the combined elements? Right now
>we have little in the way of technology or automated procedures or even
>industry experience to aid us in designing that compound DTD in a good,
>clean, and efficient way. That's a hard problem and one that some
>of the schema proposals are feeling toward a solution for. But we're
>nowhere near knowing the answer.
F. Bryan Cooper 707 823 7324
VERITAS Software 707 321 3301 mobile
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)