@@use title page builder to change stuff above here
@@ 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)
Node content must be left free to evolve. TimBL 1991
known evolving namespaces:
"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:
- 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.
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