Another look at namespaces

[Hunter, David]

From: Tim Berners-Lee [mailto:timbl at w3.org]
Sent: Wednesday, September 15, 1999 4:41 PM

> It is important to realize that these are *different* languages.
> If you take a Transition document and re-label it as a strict document
> it can be invalid. Invalid by specification, whether 
> represented by English
> or DTD or schema.

In these kinds of debates I've noticed a tendency for people to say "I think
this is the heart of the matter", so I'll give it a shot too.  ;-)  

Right now, the vast majority of people in the world consider HTML to be one
language.  Even though HTML 4 defines three variants of the language, ask
anyone on the street, or anyone in web development, and they'll tell you
that HTML is HTML is HTML.  Even though there is an HTML 3 and an HTML 2 and
an HTML 4, people still consider it one language.  (When I say "vast
majority", I mean that I'm betting the number of people who <em>don't</em>
consider HTML to be one language would be statistically insignificant.)

If the W3C is going to consider XHTML not to be an XML vocabulary, but a
"family" of XML vocabularies, then preconceived notions will have to be
changed.  Drastically.  That is, the world will have to be told "No, you're
mistaken, HTML is not one language".  Just look at the reactions on this
mailing list:  declaring that XHTML is [going to be] three languages is
producing a considerable stir, with reactions ranging from surprise to
indignation to anger.

> The namespaces spec was adamant that you could use namespaces
> without having to dereference the namespace URI.
> However, as we define languages for talking about languages
> (XML and RDF schemas for example, even style sheets)
> the document corresponding to the namespace URI becomes
> the place where the namespace-author can put *definitive*
> information about the intent of the namespace.
> And this is not mandatory - but is very useful!

To say that this is "not mandatory" may be a bit of an understatement.  As
Jon Bosak stated in an earlier email (archived at
http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Sep-1999/0385.html):

>The URI in a namespace declaration may or may not refer 
>to an actual resource that can be retrieved by a computer; 
>if it does, the resource so identified may or may not have 
>useful things to tell us about things labeled with the names 
>associated with the URI.  The statement in the Namespaces 
>Recommendation that "It is not a goal that it [the namespace 
>URI] be directly usable for retrieval of a schema (if any 
>exists)" is not mere rhetorical fluff but rather represents 
>a concrete position taken by the XML Working Group after months 
>of debate and in direct opposition to an equally concrete point 
>of view to the contrary.

I agree with Mr. Bosak's position very strongly.  As soon as you start
putting "things" at the location specified by a namespace URI, you're going
to have to start defining what kinds of "things" to put there.  (Schemas?
DTDs?  Stylesheets?  (XSL, CSS...)  ReadMe documents?  (text? HTML? XHTML?)
All of these have been suggested on this list.)  (Not to mention that the
namespace URI can no longer be a URN, but <em>must</em> be a URL.  Which
also caused quite the debate of its own on this list a few months ago...)

If the W3C does decide that they want to start putting "things" there, it
also has to be optional as to whether or not the application involved goes
to retrieve it.  (If I develop an Intranet application, I want to be able to
use XHTML without clients having to run out to the W3C site regularly.
Ditto for any other XML vocabularies which are defined going forward, from
the W3C or anyone else.)

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)