Summary of Architecture of the World Wide Web, Volume One
15 December 2004
Copyright © 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.
Status of this Document
This document is a summary of "Architecture of the World Wide Web, Volume One". 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, 2
Global Identifiers
Global naming leads to global network effects.
practice, 2.1
Identify with URIs
To benefit from and increase the value of the World Wide Web, agents should provide URIs as identifiers for resources.
constraint, 2.2
URIs Identify a Single Resource
Assign distinct URIs to distinct resources.
practice, 2.3.1
Avoiding URI aliases
A URI owner SHOULD NOT associate arbitrarily different URIs with the same resource.
practice, 2.3.1
Consistent URI usage
An agent that receives a URI SHOULD refer to the associated resource using the same URI, character-by-character.
practice, 2.4
Reuse URI schemes
A specification SHOULD reuse an existing URI scheme (rather than create a new one) when it provides the desired properties of identifiers and their relation to resources.
practice, 2.5
URI opacity
Agents making use of URIs SHOULD NOT attempt to infer properties of the referenced resource.
practice, 3.2
Reuse representation formats
New protocols created for the Web SHOULD transmit representations as octet streams typed by Internet media types.
constraint, 3.3
Data-metadata inconsistency
Agents MUST NOT ignore message metadata without the consent of the user.
practice, 3.3
Metadata association
Server managers SHOULD allow representation creators to control the metadata associated with their representations.
principle, 3.4
Safe retrieval
Agents do not incur obligations by retrieving a representation.
practice, 3.5
Available representation
A URI owner SHOULD provide representations of the resource it identifies
principle, 3.5
Reference does not imply dereference
An application developer or specification author SHOULD NOT require networked retrieval of representations each time they are referenced.
practice, 3.5.1
Consistent representation
A URI owner SHOULD provide representations of the identified resource consistently and predictably.
practice, 4.2.1
Version information
A data format specification SHOULD provide for version information.
practice, 4.2.2
Namespace policy
An XML 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.
practice, 4.2.3
Extensibility conformance
Extensibility MUST 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
Link identification
A specification SHOULD provide ways to identify links to other resources, including to secondary resources (via fragment identifiers).
practice, 4.4
Web linking
A specification SHOULD 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
Hypertext links
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 documents
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.
constraint, 4.5.5
QNames Indistinguishable from URIs
Do not allow both QNames and URIs in attribute values or element content where they are 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.
principle, 5.1
Orthogonality
Orthogonal abstractions benefit from orthogonal specifications.
principle, 5.3
Error recovery
Agents that recover from error by making a choice without the user's consent are not acting on the user's behalf.