Why namespaces?

[Edd Dumbill]

On Thu, Sep 02, 1999 at 02:58:54AM +0100, Mark Birbeck wrote:
> > Namespaces (by my reading of the spec) are for distinguishing
> > element/attribute vocabularies *within an instance*.
> 
> Not so. My server might receive this:
> 
> <com:delete>
>     <u:user>
>        <u:name>Mark</u:name>
>     </u:user>
> </com:delete>
> 
> and then five minutes later receive this:
> 
> <com:delete>
>     <c:computer>
> 	    <c:name>laptop</c:name>
>     </c:computer>
> </com:delete>
> 
> By your reckoning the fact that the first document has 'com' and 'u'
> distinct, and the second has 'com' and 'c' distinct is fine. But what if
> the first delete instruction simply referred to removing the user
> profile, and not the user? In other words, the two 'delete' nodes might
> be in different namespaces and do different things, even though they are
> not in the same document. My server would surely want to know which
> namespace they occupied. Namespaces (by my reading of the spec) are for
> distinguishing element/attribute vocabularies *within the whole world*.

>From my reading of your post it seems to be confusing the prefix with
the namespace itself. The namespace URI reference identifies the
namespace.  So, yes, namespaces can be used to distinguish vocabularies
globally, put prefixes can't.

So in the first example you have in an attribute of a containing
element:

 xmlns:com="http://foo.bar.org/commands/onesense"

and the second

 xmlns:com="http://foo.bar.org/commands/anothersense"

Therefore implementations shouldn't assume anything from a prefix, but
derive their meaning from the namespace prefix binding.  Indeed as I
understand it you can reuse a prefix within an instance, but bound to a
different namespace. 

It seems to me that the annoyance is arising because DTDs clearly are no
longer sufficient to distinguish sets of elements as namespaces allow
elements with distinct definitions to be mixed in one instance. This
seems to be the motivation from the XHTML side of things. 

It is clearly a goal of XHTML to allow inclusion of other XML namespaces
in a document, therefore XHTML ought to define the namespace within
which it sits.  And since, in HTML4 there are three DTDs which
describe distinct flavors, three namespaces are required.

It is up to the application (not the parser) how they treat the three
XHTML namespaces, but the distinction ought to be preserved until the
application level.

James Tauber said:
> >"we would only need separate namespaces for each flavour of
> > XHTML if people are going to want to mix the three flavours
> > in the one document and distinguish the different usages
> > of the element/attributes names in the intersection." 

Which is right.  It seems to be a clear aim of the XHTML PR that this
mixing be permitted for any XML namespace.   So whether three namespaces
are required depends on whether you believe that a namespace infers a
definition by which you can validate.  

Oren Ben-Kiki says:
> "Concretely, as long as the XSchema WG keeps the "namespace == schema"
> rule, I don't see how you can decide to use just one namespace for
> XHTML (much as I would like you to)"

So, if a namespace does indeed == a schema then we need three of them.

The implication of this to me seems to be nothing less than the ultimate
replacement of the DTD declaration by the namespace declaration.

> Mark

I _think_ I've ended up in a 3-namespace mood.

regards

-- 
Edd Dumbill ------/ a new media consultant, writer & technologist /--
 | Director, Useful Information Company        <http://usefulinc.com>
 | Internet Director, Pharmalicensing    <http://pharmalicensing.com>
 : UK voice/msg: +44 702-093-6870            UK fax: +44 870-164-0230


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/ and on CD-ROM/ISBN 981-02-3594-1
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)