Namespace Resources: An Essential Evolutionary Mechanism in Web Architecture

W3C Note 10 Feb 1998

This Version:
Latest Version:
Previous Version:
@@ or versions. hmm...
Dan Connolly <connolly@w3.org> W3C

@@use title page builder to change stuff above here

Status of This Document

@@ note boilerplate

@@Dan working on a note to go with XML 1.0 announcement: follows up on Dan's action item to publish PEP requirements as a separate note; sends the message to the world that yes, W3C understands the importance of namespaces; motivates the XML WG to produce them rapidly.

@@ where to send comments: www-talk

@@ custom stuff: accompanies the XML 1.0 recommendation endorsement


@@have them in programming languages (motivated by the need for separate compilation, independent development); have them in language? law? need them in XML, in HTTP (PEP, HTTP-NG)


  1. @@

from dataformats

Node content must be left free to evolve.
TimBL 1991
We want to make the Web an application platform, not just an on-line magazine. To do this, we need good programming facilities, clear and usable interfaces, and rich, clean data. Java, JavaScript, and so on give us the first. The Document Object Model, also under development in the W3C, gives us the second. XML is the third leg of the tripod, and represents a substantial part of the future of the Web.
Tim Bray

known evolving namespaces:

HTML-threading submission

MathML/HTML mixing


RDF, schemas


"graceful deployment of features in a distributed system"


distributed system in continuous operation

humpty dumpty quote

Nelson on new words

pep requirements: from HTTP Activity Statement:


The requirement is to be able to independently introduce extensions and new features to HTTP in such a way that 1) They are orthogonal to other extensions and 2) They can be deployed automatically and dynamically. HTTP/1.1 does not currently provide support for such extensions; it required a complex Protocol Extension Protocol (PEP) to accommodate dynamic extension of HTTP/1.1 and to address the tension between dynamically extensible applications and public, static specifications.

The advantage of PEP's model is that extended applications do not require agreement across the whole Internet about the extended facilities; rather, it suffices:

Many of the current problems of introducing extension into HTTP/1.1 comes from the inherent difficulties of retrofitting an extension model into an existing design.

from WD-http-pep-970428:

4. Introduction

HTTP is a generic request-response protocol, designed to accommodate a variety of applications, from network information retrieval and searching to file transfer and repository access to query and forms processing.

The agents in an HTTP transaction are a client and a server, which send HTTP messages to each other, with intermediaries between them in some cases. However, semantically, an HTTP transaction is between a client party (for example, the referent of the From: header field) and a principal responsible for the publication of a given resource.

The publishing party is the one responsible for the service provided at any particular URI, for example, the mapping between the URI and any representation of the resource to which it refers. Exactly who takes this role is beyond the scope of this document, but for example, it may be the writer of a document, the server administrator, the organization running the server, or a combination of these.

HTTP is used increasingly in applications that need more facilities than the standard version of the protocol provides, from distributed authoring, collaboration and printing, to various remote procedure call mechanisms. Many of these applications do not require agreement across the whole Internet about the extended facilities; rather, it suffices:

The need for extensibility creates a tension between dynamically extensible applications and public, static specification.

From design issues: metadata


CORBA interface identifiers
ILU typeIDs, defn interface, module
VQ's paper on mixing schemas
dublin core
modula-3's defn of interface, module
larch theories
chomsky? (grammars)? Dragon?
softer linguistics reference? Umberto Ecco's sign/signifier/sign stuff? Hallam-Baker?