Reserved names and documentation

[Bryan Cooper]

Assertion on:  
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...
/Assertion

Suggestion On:
A more explicit parser command tag like 

<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>.  

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
parsing territory.
/Suggestion

Analysis On:
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
for example.

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.
/2cents analysis

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.

...bryan

F. Bryan Cooper	 		707 823 7324 
VERITAS Software      		707 321 3301 mobile
Bryan.Cooper at veritas.com   

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