NOTE-webarch-names-0210

Namespace Resources: An Essential Evolutionary Mechanism in Web Architecture

W3C Note 10 Feb 1998

This Version:: http://www.w3.org/TR/1998/NOTE-webarch-names-0210
Latest Version:: http://www.w3.org/TR/1998/NOTE-webarch-names
Previous Version:: @@ or versions. hmm...
Author:: 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

Abstract

@@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)

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 tags
URI schemes
dns ;-)
RFC822 header fields; HTTP header fields
Dublin Core (Marc, Bibtex, ...)

HTML-threading submission

MathML/HTML mixing

SMIL/HTML

RDF, schemas

WEBDAV

"graceful deployment of features in a distributed system"

intercreativity

distributed system in continuous operation

humpty dumpty quote

Nelson on new words

pep requirements: from HTTP Activity Statement:

Extensibility

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:

That conforming peers supporting a particular protocol extension or feature can employ it dynamically with no prior agreement;
That it is possible for one party having a capability for a new protocol to require that the other party either understand and abide by the new protocol or abort the operation;
That negotiation of matching capabilities is possible.

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:

That conforming HTTP peers supporting a particular protocol extension or feature should be able to employ this in real time with no prior agreement;
That the extended HTTP protocol to the extend possible should be able to work through HTTP proxies - especially caching proxies;
That it should be possible for one party having a capability for a new protocol to require that the other party either understand and abide by the new protocol or abort the operation;
That negotiation of matching capabilities should be possible.

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

From design issues: metadata

References

WD-doctypes
PEP
COM IIDs
CORBA interface identifiers
ILU typeIDs, defn interface, module
VQ's paper on mixing schemas
smil
HTML
RDF
WEBDAV
dublin core
modula-3's defn of interface, module
Java
larch theories
Kuipers/Algernon?
GEB?
chomsky? (grammars)? Dragon?
softer linguistics reference? Umberto Ecco's sign/signifier/sign stuff? Hallam-Baker?