W3C home > Mailing lists > Public > xml-names-issues@w3.org > October to December 1998

Default Namespace should be clearly documented and supported by specific <TAG> type

From: Bryan Cooper <bryan.cooper@veritas.com>
Date: Sun, 29 Nov 1998 13:05:36 -0800
Message-Id: <199811292104.NAA11338@mailhub1.ncal.verio.com>
To: xml-names-issues@w3.org
I would like the namespace specification to show examples of how to switch the
default namespace using a clear tagging convention. I'd REALLY like to see a
generalized  notation used for that tagging convention. I'd like to see an
example of how to do the following:  


In the DTD, I'd like to see this type of syntax:  The first 

 MUST BE , and the second 

 would be automatically default namespace parsed as belonging to the 2nd
namespace. This approach simplifies the need to tag ENTITIES at all, but
instead lets the parser know which default namespace is in effect. The
EVENT is
a new type of entity and the TYPE statement could become more explicit in XML
over time to support different types of parser specific tweaks. I assume I
could use an ENTITY for this but then I should have the ENTITY cover all the
possible ENTITIES in the DTD in terms of encapsulation. Is this supported by
the draft? It wasn't clear from the example that a namespace change tag is
supported by the DTD as a specific type of "switch default namespace tag", but
I think it is available. I'd just like to see it clearly documented in the
spec, and I am suggesting the EVENT addition to XML as a means of making it
even more explicit. The DTD should clearly allow the definition of the context
switch tag in "different_ns" such as shown above in . These tags would be then
be the only tags requiring the namespace prefix, since all included tags must
then be supported by the "different_ns", UNLESS they include a different
namespace prefix. In fact, the use of the different namespace prefix is just a
one time example of pushing the context to a different namespace. The example
in the spec implies that all enclosed tags will be in the different namespace.
It should also show that specified namespace prefix tags do NOT cause such as
shift:  

.  


.  I am working on another suggestion generalizing the ability of XML to
support
events, but the default namespace issue is a good example of what an event can
do to help. In this case, I'd like to see in the NAMESPACE specification the
ability for DTD to declare the push namespace default EVENT . The way the spec
currently reads, this push namespace is IMPLIED, not EXPLICIT in the DTD. This
event tag requires a namespace context switch plus a namespace stack push to
save the old namespace context. XML is perfect for stack/context switching and
we need some generalized way to talk about other kinds of events. What we
would
see in the spec then would be 3 methods to determine current default
namespace.
The current proposal where 1) the xmlns is used inline in the doc, 2) where
the
context is determine by a higher level tag such as , and 3) where the default
context is pushed by new tags declared in the DTD solely for the purpose of
changing the current default, and which could be used to pass other
parameters.
I think it would be more efficient to have this third type of tag since it
means the DTD would not need to have every tag setup for pushing the namespace
into the appropriate context as I think is implied by the current spec. If
every DTD tag is setup for pushing the namespace the parsing of every tag is
going to get expensive over time. I'd rather not have any tag in a DTD setup
specifically with the namespace EXCEPT for minimally one which I am proposing
as a namespace EVENT. I don't want this namespace tag to require a whole bunch
of ENTITIES encapsulation within the DTD. I just want to be able to simply
declare it as namespace EVENT so the parser knows to push the default
namespace
context. 
...bryan

F. Bryan Cooper	 		707 823 7324 
VERITAS Software      		707 321 3301 mobile
Bryan.Cooper@veritas.com   
Received on Sunday, 29 November 1998 16:04:36 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Tuesday, 12 April 2005 12:17:17 GMT