Reserved names and documentation

[Bryan Cooper]

Marcus - thanx for the fast feedback.  I am not proposing a complete
solution but rather on top of the existing namespace proposal. 
I am also talking just at a general level of "does this tag allow
ANY entry from namespace "newnamespace"?  I am not trying
to handle more delicate parsing within namespace.  Apps would still be able
to explicitly set namespace at each <TAG> as currently proposed, but without the
needed parsing clues for the primary DTD.   

Rather, I am saying this is an approach that would work for
a number of types of XML documents.  I believe merging DTDs
will make XML namespace a big fat mess and defeat the purpose of namespace,
since then the DTD just get bigger and bigger so why bother supporting
multiple DTD anyway?  For some purposes, telling the parser "Hey! Look!
This is the same as "SUBDOC" so what is so wrong with supporting that
for apps?  I could go with 
<DOCTYPE>
<SUBDOCTYPE XXX  xml:=...> in the main header,
defining <XXX> as the namespace encapsulation tag.  The DTD would
then need similar generic SUBDOCTYPE which equates XXX with valid namespace
tags that it allows.  Only the primary DTD would check that the namespace is valid,
and not care whether XXX was the actual TAG used or YYY or whatever,
just that the switched namespace had been placed within appropriate TAG.  
Again, I am starting just from the gross level where
now the primary DTD can at least accept subdocs without necessarily
having fine application level control within those subdocs.

This would be a nice clean implementation and would allow the primary
DTD to determine just which embedded namespaces it accepts (AND WHERE)
by using a new keyword (or defined on the fly in each additional DOCTYPE
as another suggestion ).  

In short, I don't see how the current proposal allows DTDs to reject
embedded namespaces since there needs to be a way to communicate
that rule to the parser in the primary DTD.  Using a new keyword
like <EVENT> is just one method,  (or <SUBDOCTYPE XXX namespace="new">) 
for the primary DTD elements...  Then <XXX> would be parsed
by the primary DTD, and mean "change the namespace!"... 

I guess I am saying that there is a hierarchy to applications, where there
really is <DOCTYPE> at the "current" highest level, and it should allow that
doctype to control subdoctype/namespace as requested by the huddled masses.    
We need a keyword to simplify the namespace switch within the DTD, 
not necessarily within the actual document as I am suggesting.  Going totally 
granular on this may be necessary for some apps/DTDs, but what about alot of 
other apps where we just need to know the gross level namespace 
switch is about to occur?  I have an application today where that would
be helpful..

How do we allow/disallow that within the DTD today?  Then let's
drill down to the leaf node if people want/need such complicated DTDs.

As to the committee deliberations, I won't go into the standard definition of "assume"... :-?   I know that the current proposal makes a lot of sense,
BUT it needs some tuning on this particular issue.  

At 03:29 PM 1/6/99 +1100, Marcus Carr wrote:
>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 at 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 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)
> 
...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)