Summary of Architecture of the World Wide Web, First Edition

10 May 2004

Status of this Document

This document is a summary of "Architecture of the World Wide Web, First Edition". The goal of the current document is to present the Architecture Document's principles, constraints, and good practice notes in an abbreviated format. Each entry has a title, the type of entry (principles, constraints, or good practice note), section of the Architecture Document where it is discussed, followed by the entry text. The current document is only a summary and should not be used for reference.

This document has been developed by W3C's Technical Architecture Group (TAG) (charter).

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than "work in progress."

principle, 1.2.3

Error recovery

Agent recovery from error without user consent is harmful.

constraint, 2

Identify with URIs

The identification mechanism for the Web is the URI.

principle, 2

URI assignment

One should assign a URI to anything that others will expect to refer to.

constraint, 2.1

URI multiplicity

Web architecture does not constrain a resource to be identified by a single URI.

practice, 2.1.1

Avoiding URI aliases

A URI owner should not create arbitrarily different URIs for the same resource.

practice, 2.1.1

Consistent URI usage

If a URI has been assigned to a resource, agents SHOULD refer to the resource using the same URI, character for character.

practice, 2.2

Avoiding URI Overloading

Avoid URI overloading.

practice, 2.4

New URI schemes

A specification SHOULD NOT introduce a new URI scheme when an existing scheme provides the desired properties of identifiers and their relation to resources.

practice, 2.5

URI opacity

Agents making use of URIs MUST NOT attempt to infer properties of the referenced resource except as licensed by relevant specifications.

practice, 3.3.2

Fragment identifier consistency

The owner of a URI with a fragment identifier who uses content negotiation to serve multiple representations of the identified resource SHOULD NOT serve representations with inconsistent fragment identifier semantics.

principle, 3.4.1

Authoritative metadata

Agents MUST NOT ignore authoritative metadata without the consent of the user.

principle, 3.5

Safe retrieval

Agents do not incur obligations by retrieving a representation.

practice, 3.6

Consistent representation

A URI owner SHOULD provide representations of the identified resource consistently and predictably.

practice, 3.6.1

Available representation

A URI owner SHOULD provide representations of the identified resource.

practice, 4.2.1

Version information

A format specification SHOULD provide for version information in language instances.

practice, 4.2.2

Namespace policy

A format specification SHOULD include information about change policies for XML namespaces.

practice, 4.2.3

Extensibility mechanisms

A specification SHOULD provide mechanisms that allow any party to create extensions that do not interfere with conformance to the original specification.

practice, 4.2.3

Unknown extensions

A specification SHOULD specify agent behavior in the face of unrecognized extensions.

practice, 4.3

Separation of content, presentation, interaction

A specification SHOULD allow authors to separate content from both presentation and interaction concerns.

practice, 4.4

A specification SHOULD provide mechanisms for identifying links to other resources and to portions of representation data (via fragment identifiers).

practice, 4.4

Web linking

A specification SHOULD provide mechanisms that allow Web-wide linking, not just internal document linking.

practice, 4.4

Generic URIs

A specification SHOULD allow content authors to use URIs without constraining them to a limited set of URI schemes.

practice, 4.4

A data format SHOULD incorporate hypertext links if hypertext is the expected user interface paradigm.

practice, 4.5.3

Namespace adoption

A specification that establishes an XML vocabulary SHOULD place all element names and global attribute names in a namespace.

practice, 4.5.4

Namespace representations

The owner of an XML namespace name SHOULD make available material intended for people to read and material optimized for software agents in order to meet the needs of those who will use the namespace vocabulary. When a namespace representation is provided by the namespace URI owner, that material is authoritative.

practice, 4.5.5

QNames Indistinguishable from URIs

A specification in which QNames represent URI/local-name pairs SHOULD NOT allow both Qnames and URIs in attribute values or element content, where they would be indistinguishable.

practice, 4.5.5

QName Mapping

A specification in which QNames serve as resource identifiers MUST provide a mapping to URIs.

practice, 4.5.7

XML and "text/*"

In general, a representation provider SHOULD NOT assign Internet media types beginning with "text/" to XML representations.

practice, 4.5.7

XML and character encodings

In general, a representation provider SHOULD NOT specify the character encoding for XML data in protocol headers since the data is self-describing.