TheWorld Wide Web (WWW, orsimplyWeb) is an informationspace in which the items of interest, referred to as resources, areidentified by global identifiers called Uniform ResourceIdentifiers (URI).
Examples such as the followingtravel scenarioare used throughout this document to illustrate typical behavior ofWebagents—people or software acting on this informationspace. Auseragent acts on behalf of a user. Software agents includeservers, proxies, spiders, browsers, and multimedia players.
Story
While planning a trip to Mexico,Nadia reads “Oaxaca weather information:'http://weather.example.com/oaxaca'” in a glossy travel magazine.Nadia has enough experience with the Web to recognize that"http://weather.example.com/oaxaca" is a URI and that she is likelyto be able to retrieve associated information with her Web browser.When Nadia enters the URI into her browser:
- The browser recognizes that what Nadia typed is a URI.
- The browser performs an information retrieval action inaccordance with its configured behavior for resources identifiedvia the "http" URI scheme.
- The authority responsible for "weather.example.com" providesinformation in a response to the retrieval request.
- The browser interprets the response, identified as XHTML by theserver, and performs additional retrieval actions for inlinegraphics and other content as necessary.
- The browser displays the retrieved information, which includeshypertext links to other information. Nadia can follow thesehypertext links to retrieve additional information.
This scenario illustrates the threearchitectural bases of the Web that are discussed in thisdocument:
Identification (§2). URIs are used to identifyresources. In this travel scenario, the resource is a periodicallyupdated report on the weather in Oaxaca, and the URI is“http://weather.example.com/oaxaca”.
Interaction (§3). Web agents communicate usingstandardized protocols that enable interaction through the exchangeof messages which adhere to a defined syntax and semantics. Byentering a URI into a retrieval dialog or selecting a hypertextlink, Nadia tells her browser to perform a retrieval action for theresource identified by the URI. In this example, the browser sendsan HTTP GET request (part of the HTTP protocol) to the server at"weather.example.com", via TCP/IP port 80, and the server sendsback a message containing what it determines to be a representationof the resource as of the time that representation was generated.Note that this example is specific to hypertext browsing ofinformation—other kinds of interaction are possible, both withinbrowsers and through the use of other types of Web agent; ourexample is intended to illustrate one common interaction, notdefine the range of possible interactions or limit the ways inwhich agents might use the Web.
Formats (§4). Most protocols used for representationretrieval and/or submission make use of a sequence of one or moremessages, which taken together contain a payload of representationdata and metadata, to transfer the representation between agents.The choice of interaction protocol places limits on the formats ofrepresentation data and metadata that can be transmitted. HTTP, forexample, typically transmits a single octet stream plus metadata,and uses the "Content-Type" and "Content-Encoding" header fields tofurther identify the format of the representation. In thisscenario, the representation transferred is in XHTML, as identifiedby the "Content-type" HTTP header field containing the registeredInternet media type name, "application/xhtml+xml". That Internetmedia type name indicates that the representation data can beprocessed according to the XHTML specification.
Nadia's browser is configured andprogrammed to interpret the receipt of an "application/xhtml+xml"typed representation as an instruction to render the content ofthat representation according to the XHTML rendering model,including any subsidiary interactions (such as requests forexternal style sheets or in-line images) called for by therepresentation. In the scenario, the XHTML representation datareceived from the initial request instructs Nadia's browser to alsoretrieve and render in-line the weather maps, each identified by aURI and thus causing an additional retrieval action, resulting inadditional representations that are processed by the browseraccording to their own data formats (e.g., "application/svg+xml"indicates the SVG data format), and this process continues untilall of the data formats have been rendered. The result of all ofthis processing, once the browser has reached an applicationsteady-state that completes Nadia's initial requested action, iscommonly referred to as a "Web page".
The following illustration shows therelationship between identifier, resource, and representation.
In the remainder of this document, wehighlight important architectural points regarding Web identifiers,protocols, and formats. We also discuss some importantgeneral architectural principles (§5)and how they apply to the Web.
This document describes theproperties we desire of the Web and the design choices that havebeen made to achieve them. It promotes the reuse of existingstandards when suitable, and gives guidance on how to innovate in amanner consistent with Web architecture.
The terms MUST, MUST NOT, SHOULD,SHOULD NOT, and MAY are used in the principles, constraints, andgood practice notes in accordance with RFC 2119 [RFC2119].
This document does not includeconformance provisions for these reasons:
- Conforming software is expected to be so diverse that it wouldnot be useful to be able to refer to the class of conformingsoftware agents.
- Some of the good practice notes concern people; specificationsgenerally define conformance for software, not people.
- We do not believe that the addition of a conformance section islikely to increase the utility of the document.
This document is intended to informdiscussions about issues of Web architecture. The intended audiencefor this document includes:
- Participants in W3C Activities
- Other groups and individuals designing technologies to beintegrated into the Web
- Implementers of W3C specifications
- Web content authors and publishers
Note: This documentdoes not distinguish in any formal way the terms "language" and"format." Context determines which term is used. The phrase"specification designer" encompasses language, format, and protocoldesigners.
This document presents the generalarchitecture of the Web. Other groups inside and outside W3C alsoaddress specialized aspects of Web architecture, includingaccessibility, quality assurance, internationalization, deviceindependence, and Web Services. The section onArchitectural Specifications (§7.1) includesreferences to these related specifications.
This document strives for a balancebetween brevity and precision while including illustrativeexamples.TAG findings are informational documents that complementthe current document by providing more detail about selectedtopics. This document includes some excerpts from the findings.Since the findings evolve independently, this document includesreferences to approved TAG findings. For other TAG issues coveredby this document but without an approved finding, references are toentries in theTAG issues list.
Many of the examples in this documentthat involve human activity suppose the familiar Web interactionmodel (illustrated at the beginning of the Introduction) where aperson follows a link via a user agent, the user agent retrievesand presents data, the user follows another link, etc. Thisdocument does not discuss in any detail other interaction modelssuch as voice browsing (see, for example, [VOICEXML2]). The choice of interaction model mayhave an impact on expected agent behavior. For instance, when agraphical user agent running on a laptop computer or hand-helddevice encounters an error, the user agent can report errorsdirectly to the user through visual and audio cues, and present theuser with options for resolving the errors. On the other hand, whensomeone is browsing the Web through voice input and audio-onlyoutput, stopping the dialog to wait for user input may reduceusability since it is so easy to "lose one's place" when browsingwith only audio-output. This document does not discuss how theprinciples, constraints, and good practices identified here applyin all interaction contexts.
The important points of this documentare categorized as follows:
- Principle
- An architectural principle is a fundamental rule that appliesto a large number of situations and variables. Architecturalprinciples include "separation of concerns", "generic interface","self-descriptive syntax," "visible semantics," "network effect"(Metcalfe's Law), and Amdahl's Law: "The speed of a system islimited by its slowest component."
- Constraint
- In the design of the Web, some choices, like the names of the
p andli elements in HTML, the choice ofthe colon (:) character in URIs, or grouping bits into eight-bitunits (octets), are somewhat arbitrary; ifparagraphhad been chosen instead ofp or asterisk (*) insteadof colon, the large-scale result would, most likely, have been thesame. This document focuses on more fundamental design choices:design choices that lead to constraints, i.e., restrictions inbehavior or interaction within the system. Constraints may beimposed for technical, policy, or other reasons to achievedesirable properties in the system, such as accessibility, globalscope, relative ease of evolution, efficiency, and dynamicextensibility. - Goodpractice
- Good practice—by software developers, content authors, sitemanagers, users, and specification designers—increases the value ofthe Web.
In order to communicate internally, acommunity agrees (to a reasonable extent) on a set of terms andtheir meanings. One goal of the Web, since its inception, has beento build a global community in which any party can shareinformation with any other party. To achieve this goal, the Webmakes use of a single global identification system: the URI. URIsare a cornerstone of Web architecture, providing identificationthat is common across the Web. The global scope of URIs promoteslarge-scale "network effects": the value of an identifier increasesthe more it is used consistently (for example, the more it is usedinhypertextlinks (§4.4)).
This principle dates back at least asfar as Douglas Engelbart's seminal work on open hypertext systems;see sectionEvery Object Addressable in [Eng90].
The choice of syntax for globalidentifiers is somewhat arbitrary; it is their global scope that isimportant. TheUniform ResourceIdentifier, [URI], hasbeen successfully deployed since the creation of the Web. There aresubstantial benefits to participating in the existing network ofURIs, including linking, bookmarking, caching, and indexing bysearch engines, and there are substantial costs to creating a newidentification system that has the same properties as URIs.
Goodpractice:Identify with URIs
To benefit from andincrease the value of the World Wide Web, agents should provideURIs as identifiers for resources.
A resource should have an associatedURI if another party might reasonably want to create a hypertextlink to it, make or refute assertions about it, retrieve or cache arepresentation of it, include all or part of it by reference intoanother representation, annotate it, or perform other operations onit. Software developers should expect that sharing URIs acrossapplications will be useful, even if that utility is not initiallyevident. The TAG finding"URIs, Addressability, and the use of HTTP GET andPOST" discusses additional benefits and considerationsof URI addressability.
Note: Some URIschemes (such as the "ftp" URI scheme specification) use the term"designate" where this document uses "identify."
By design a URI identifies oneresource. We do not limit the scope of what might be aresource. The term"resource" is used in a general sense for whatever might beidentified by a URI. It is conventional on the hypertext Web todescribe Web pages, images, product catalogs, etc. as “resources”.The distinguishing characteristic of these resources is that all oftheir essential characteristics can be conveyed in a message. Weidentify this set as “informationresources.”
This document is an example of aninformation resource. It consists of words and punctuation symbolsand graphics and other artifacts that can be encoded, with varyingdegrees of fidelity, into a sequence of bits. There is nothingabout the essential information content of this document thatcannot in principle be transfered in a message. In the case of thisdocument, the message payload is therepresentation of this document.
However, our use of the term resourceis intentionally more broad. Other things, such as cars and dogs(and, if you've printed this document on physical sheets of paper,the artifact that you are holding in your hand), are resources too.They are not information resources, however, because their essenceis not information. Although it is possible to describe a greatmany things about a car or a dog in a sequence of bits, the sum ofthose things will invariably be an approximation of the essentialcharacter of the resource.
We define the term “informationresource” because we observe that it is useful in discussions ofWeb technology and may be useful in constructing specifications forfacilities built for use on the Web.
Since the scope of a URI is global,the resource identified by a URI does not depend on the context inwhich the URI appears (see also the section aboutindirectidentification (§2.2.3)).
[URI]is an agreement about how the Internet community allocates namesand associates them with the resources they identify. URIs aredivided intoschemes (§2.4)that define, via their scheme specification, the mechanism by whichscheme-specific identifiers are associated with resources. Forexample, the "http" URI scheme ([RFC2616]) uses DNS and TCP-based HTTP servers for thepurpose of identifier allocation and resolution. As a result,identifiers such as "http://example.com/somepath#someFrag" oftentake on meaning through the community experience of performing anHTTP GET request on the identifier and, if given a successfulresponse, interpreting the response as a representation of theidentified resource. (See alsoFragment Identifiers (§2.6).) Of course, a retrievalaction like GET is not the only way to obtain information about aresource. One might also publish a document that purports to definethe meaning of a particular URI. These other sources of informationmay suggest meanings for such identifiers, but it's a local policydecision whether those suggestions should be heeded.
Just as one might wish to refer to aperson by different names (by full name, first name only, sportsnickname, romantic nickname, and so forth), Web architecture allowsthe association of more than one URI with a resource. URIs thatidentify the same resource are calledURI aliases. The section onURI aliases (§2.3.1)discusses some of the potential costs of creating multiple URIs forthe same resource.
Several sections of this documentaddress questions about the relationship between URIs andresources, including:
By design, a URI identifies oneresource. Using the same URI to directly identify differentresources produces aURI collision. Collision oftenimposes a cost in communication due to the effort required toresolve ambiguities.
Suppose, for example, that oneorganization makes use of a URI to refer to the movieTheSting, and another organization uses the same URI to referto a discussion forum aboutThe Sting. To a thirdparty, aware of both organizations, this collision createsconfusion about what the URI identifies, undermining the value ofthe URI. If one wanted to talk about the creation date of theresource identified by the URI, for instance, it would not be clearwhether this meant "when the movie was created" or "when thediscussion forum about the movie was created."
Social and technical solutions havebeen devised to help avoid URI collision. However, the success orfailure of these different approaches depends on the extent towhich there is consensus in the Internet community on abiding bythe defining specifications.
The section onURI allocation (§2.2.2)examines approaches for establishing the authoritative source ofinformation about what resource a URI identifies.
URIs are sometimes used forindirect identification(§2.2.3). This does not necessarily lead to collisions.
URI allocation is the process ofassociating a URI with a resource. Allocation can be performed bothby resource owners and by other parties. It is important to avoidURI collision(§2.2.1).
URI ownership is a relationbetween a URI and a social entity, such as a person, organization,or specification. URI ownership gives the relevant social entitycertain rights, including:
- to pass on ownership of some or all owned URIs to anotherowner—delegation; and
- to associate a resource with an owned URI—URI allocation.
By social convention, URI ownershipis delegated from the IANA URI scheme registry [IANASchemes], itself a socialentity, to IANA-registered URI scheme specifications. Some URIscheme specifications further delegate ownership to subordinateregistries or to other nominated owners, who may further delegateownership. In the case of a specification, ownership ultimatelylies with the community that maintains the specification.
The approach taken for the "http" URIscheme, for example, follows the pattern whereby the Internetcommunity delegates authority, via the IANA URI scheme registry andthe DNS, over a set of URIs with a common prefix to one particularowner. One consequence of this approach is the Web's heavy relianceon the central DNS registry. A different approach is taken by theURN Syntax scheme [RFC2141]which delegates ownership of portions of URN space to URN Namespacespecifications which themselves are registered in anIANA-maintained registry of URN Namespace Identifiers.
URI owners are responsible foravoiding the assignment of equivalent URIs to multiple resources.Thus, if a URI scheme specification does provide for the delegationof individual or organized sets of URIs, it should take pains toensure that ownership ultimately resides in the hands of a singlesocial entity. Allowing multiple owners increases the likelihood ofURI collisions.
URI owners may organize or deployinfrastruture to ensure that representations of associatedresources are available and, where appropriate, interaction withthe resource is possible through the exchange of representations.There are social expectations for responsiblerepresentationmanagement (§3.5) by URI owners. Additional social implicationsof URI ownership are not discussed here.
See TAG issuesiteData-36, which concerns the expropriation of namingauthority.
Some schemes use techniques otherthan delegated ownership to avoid collision. For example, thespecification for the data URL (sic) scheme [RFC2397] specifies that the resource identified bya data scheme URI has only one possible representation. Therepresentation data makes up the URI that identifies that resource.Thus, the specification itself determines how data URIs areallocated; no delegation is possible.
Other schemes (such as"news:comp.text.xml") rely on a social process.
To say that the URI"mailto:nadia@example.com" identifies both an Internet mailbox andNadia, the person, introduces a URI collision. However, we can usethe URI to indirectly identify Nadia. Identifiers are commonly usedin this way.
Listening to a news broadcast, onemight hear a report on Britain that begins, "Today, 10 DowningStreet announced a series of new economic measures." Generally, "10Downing Street" identifies the official residence of Britain'sPrime Minister. In this context, the news reporter is using it (asEnglish rhetoric allows) to indirectly identify the Britishgovernment. Similarly, URIs identify resources, but they can alsobe used in many constructs to indirectly identify other resources.Globally adopted assignment policies make some URIs appealing asgeneral-purpose identifiers. Local policy establishes what theyindirectly identify.
Suppose thatnadia@example.com is Nadia's email address. Theorganizers of a conference Nadia attends might use"mailto:nadia@example.com" to refer indirectly to her (e.g., byusing the URI as a database key in their database of conferenceparticipants). This does not introduce a URI collision.
URIs that are identical,character-by-character, refer to the same resource. Since WebArchitecture allows the association of multiple URIs with a givenresource, two URIs that are not character-by-character identicalmay still refer to the same resource. Different URIs do notnecessarily refer to different resources but there is generally ahigher computational cost to determine that different URIs refer tothe same resource.
To reduce the risk of a falsenegative (i.e., an incorrect conclusion that two URIs do not referto the same resource) or a false positive (i.e., an incorrectconclusion that two URIs do refer to the same resource), somespecifications describe equivalence tests in addition tocharacter-by-character comparison. Agents that reach conclusionsbased on comparisons that are not licensed by the relevantspecifications take responsibility for any problems that result;see the section onerror handling (§5.3) for more information aboutresponsible behavior when reaching unlicensed conclusions. Section6 of [URI] provides moreinformation about comparing URIs and reducing the risk of falsenegatives and positives.
See also theassertion that two URIs identifythe same resource (§2.7.2).
Although there are benefits (such asnaming flexibility) to URI aliases, there are also costs. URIaliases are harmful when they divide the Web of related resources.A corollary of Metcalfe's Principle (the "network effect") is thatthe value of a given resource can be measured by the number andvalue of other resources in its network neighborhood, that is, theresources that link to it.
The problem with aliases is that ifhalf of the neighborhood points to one URI for a given resource,and the other half points to a second, different URI for that sameresource, the neighborhood is divided. Not only is the aliasedresource undervalued because of this split, the entire neighborhoodof resources loses value because of the missing second-orderrelationships that should have existed among the referringresources by virtue of their references to the aliasedresource.
Goodpractice:Avoiding URI aliases
A URI owner SHOULDNOT associate arbitrarily different URIs with the sameresource.
URI consumers also have a role inensuring URI consistency. For instance, when transcribing a URI,agents should not gratuitously percent-encode characters. The term"character" refers to URI characters as defined in section 2 of[URI]; percent-encoding isdiscussed in section 2.1 of that specification.
Goodpractice:Consistent URI usage
An agent thatreceives a URI SHOULD refer to the associated resource using thesame URI, character-by-character.
When a URI alias does become commoncurrency, theURI ownershould use protocol techniques such as server-side redirects torelate the two resources. The community benefits when the URI ownersupports redirection of an aliased URI to the corresponding"official" URI. For more information on redirection, see section10.3, Redirection, in [RFC2616]. See also [CHIPS] for a discussion of some best practices forserver administrators.
URI aliasing only occurs when morethan one URI is used to identify the same resource. The fact thatdifferent resources sometimes have the same representation does notmake the URIs for those resources aliases.
Story
Dirk would like to add a link fromhis Web site to the Oaxaca weather site. He uses the URIhttp://weather.example.com/oaxaca and labels his link “report onweather in Oaxaca on 1 August 2004”. Nadia points out toDirk that he is setting misleading expectations for the URI he hasused. The Oaxaca weather site policy is that the URI in questionidentifies a report on the current weather in Oaxaca—on any givenday—and not the weather on 1 August. Of course, on the first ofAugust in 2004, Dirk's link will be correct, but the rest of thetime he will be misleading readers. Nadia points out to Dirk thatthe managers of the Oaxaca weather site do make available adifferent URI permanently assigned to a resource reporting on theweather on 1 August 2004.
In this story, there are tworesources: “a report on the current weather in Oaxaca” and “areport on the weather in Oaxaca on 1 August 2004”. Themanagers of the Oaxaca weather site assign two URIs to these twodifferent resources. On 1 August 2004, therepresentations for these resources are identical. That fact thatdereferencing two different URIs produces identical representationsdoes not imply that the two URIs are aliases.
In the URI"http://weather.example.com/", the "http" that appears before thecolon (":") names a URI scheme. Each URI scheme has a specificationthat explains the scheme-specific details of how scheme identifiersare allocated and become associated with a resource. The URI syntaxis thus a federated and extensible naming system wherein eachscheme's specification may further restrict the syntax andsemantics of identifiers within that scheme.
Examples of URIs from various schemesinclude:
- mailto:joe@example.org
- ftp://example.org/aDirectory/aFile
- news:comp.infosystems.www
- tel:+1-816-555-1212
- ldap://ldap.example.org/c=GB?objectClass?one
- urn:oasis:names:tc:entity:xmlns:xml:catalog
While Web architecture allows thedefinition of new schemes, introducing a new scheme is costly. Manyaspects of URI processing are scheme-dependent, and a large amountof deployed software already processes URIs of well-known schemes.Introducing a new URI scheme requires the development anddeployment not only of client software to handle the scheme, butalso of ancillary agents such as gateways, proxies, and caches. See[RFC2718] for otherconsiderations and costs related to URI scheme design.
Because of these costs, if a URIscheme exists that meets the needs of an application, designersshould use it rather than invent one.
Goodpractice:Reuse URI schemes
A specificationSHOULD reuse an existing URI scheme (rather than create a new one)when it provides the desired properties of identifiers and theirrelation to resources.
Consider ourtravel scenario: should the agent providinginformation about the weather in Oaxaca register a new URI scheme"weather" for the identification of resources related to theweather? They might then publish URIs such as"weather://travel.example.com/oaxaca". When a software agentdereferences such a URI, if what really happens is that HTTP GET isinvoked to retrieve a representation of the resource, then an"http" URI would have sufficed.
The Internet Assigned NumbersAuthority (IANA) maintains a registry [IANASchemes] of mappings betweenURI scheme names and scheme specifications. For instance, the IANAregistry indicates that the "http" scheme is defined in [RFC2616]. The process for registering anew URI scheme is defined in [RFC2717].
Unregistered URI schemes SHOULD NOTbe used for a number of reasons:
- There is no generally accepted way to locate the schemespecification.
- Someone else may be using the scheme for other purposes.
- One should not expect that general-purpose software will doanything useful with URIs of this scheme beyond URIcomparison.
One misguided motivation forregistering a new URI scheme is to allow a software agent to launcha particular application when retrieving a representation. The samething can be accomplished at lower expense by dispatching insteadon the type of the representation, thereby allowing use of existingtransfer protocols and implementations.
Even if an agent cannot processrepresentation data in an unknown format, it can at least retrieveit. The data may contain enough information to allow a user or useragent to make some use of it. When an agent does not handle a newURI scheme, it cannot retrieve a representation.
When designing a new data format, thepreferred mechanism to promote its deployment on the Web is theInternet media type (seeRepresentation Types and Internet Media Types (§3.2)).Media types also provide a means for building new informationapplications, as described infuture directions for data formats (§4.6).
It is tempting to guess the nature ofa resource by inspection of a URI that identifies it. However, theWeb is designed so that agents communicate resource informationstate throughrepresentations, not identifiers. In general, one cannotdetermine the type of a resource representation by inspecting a URIfor that resource. For example, the ".html" at the end of"http://example.com/page.html" provides no guarantee thatrepresentations of the identified resource will be served with theInternet media type "text/html". The publisher is free to allocateidentifiers and define how they are served. The HTTP protocol doesnot constrain the Internet media type based on the path componentof the URI; the URI owner is free to configure the server to returna representation using PNG or any other data format.
Resource state may evolve over time.Requiring a URI owner to publish a new URI for each change inresource state would lead to a significant number of brokenreferences. For robustness, Web architecture promotes independencebetween an identifier and the state of the identified resource.
Goodpractice:URI opacity
Agents making useof URIs SHOULD NOT attempt to infer properties of the referencedresource.
In practice, a small number ofinferences can be made because they are explicitly licensed by therelevant specifications. Some of these inferences are discussed inthedetails ofretrieving a representation (§3.1.1).
The example URI used in thetravel scenario("http://weather.example.com/oaxaca") suggests to a human readerthat the identified resource has something to do with the weatherin Oaxaca. A site reporting the weather in Oaxaca could just aseasily be identified by the URI "http://vjc.example.com/315". Andthe URI "http://weather.example.com/vancouver" might identify theresource "my photo album."
On the other hand, the URI"mailto:joe@example.com" indicates that the URI refers to amailbox. The "mailto" URI scheme specification authorizes agents toinfer that URIs of this form identify Internet mailboxes.
Some URI assignment authoritiesdocument and publish their URI assignment policies. For moreinformation about URI opacity, see TAG issuesmetaDataInURI-31 andsiteData-36.
Story
When browsing the XHTML documentthat Nadia receives as a representation of the resource identifiedby "http://weather.example.com/oaxaca", she finds that the URI"http://weather.example.com/oaxaca#weekend" refers to the part ofthe representation that conveys information about the weekendoutlook. This URI includes the fragment identifier "weekend" (thestring after the "#").
Thefragment identifier component of a URIallows indirect identification of asecondaryresource by reference to a primary resource andadditional identifying information. The secondary resource may besome portion or subset of the primary resource, some view onrepresentations of the primary resource, or some other resourcedefined or described by those representations. The terms "primaryresource" and "secondary resource" are defined in section 3.5 of[URI].
The terms “primary” and “secondary”in this context do not limit the nature of the resource—they arenot classes. In this context, primary and secondary simply indicatethat there is a relationship between the resources for the purposesof one URI: the URI with a fragment identifier. Any resource can beidentified as a secondary resource. It might also be identifiedusing a URI without a fragment identifier, and a resource may beidentified as a secondary resource via multiple URIs. The purposeof these terms is to enable discussion of the relationship betweensuch resources, not to limit the nature of a resource.
The interpretation of fragmentidentifiers is discussed in the section onmedia types and fragmentidentifier semantics (§3.2.1).
See TAG issueabstractComponentRefs-37, which concerns the useof fragment identifiers with namespace names to identify abstractcomponents.
There remain open questionsregarding identifiers on the Web.
The integration ofinternationalized identifiers (i.e., composed of characters beyondthose allowed by [URI]) into theWeb architecture is an important and open issue. See TAG issueIRIEverywhere-27 for discussion about work goingon in this area.
Emerging Semantic Web technologies,including the "Web Ontology Language (OWL)" [OWL10], define RDF properties such assameAs to assert that two URIs identify the sameresource orinverseFunctionalProperty to imply it.
Communication between agents over anetwork about resources involves URIs, messages, and data. TheWeb's protocols (including HTTP, FTP, SOAP, NNTP, and SMTP) arebased on the exchange of messages. Amessage may include data as well asmetadata about a resource (such as the "Alternates" and "Vary" HTTPheaders), the message data, and the message itself (such as the"Transfer-encoding" HTTP header). A message may even includemetadata about the message metadata (for message-integrity checks,for instance).
Story
Nadia follows a hypertext linklabeled "satellite image" expecting to retrieve a satellite photoof the Oaxaca region. The link to the satellite image is an XHTMLlink encoded as<ahref="http://example.com/satimage/oaxaca">satelliteimage</a>. Nadia's browser analyzes the URI anddetermines that itsschemeis "http". The browser configuration determines how it locates theidentified information, which might be via a cache of priorretrieval actions, by contacting an intermediary (such as a proxyserver), or by direct access to the server identified by a portionof the URI. In this example, the browser opens a network connectionto port 80 on the server at "example.com" and sends a "GET" messageas specified by the HTTP protocol, requesting a representation ofthe resource.
The server sends a response messageto the browser, once again according to the HTTP protocol. Themessage consists of several headers and a JPEG image. The browserreads the headers, learns from the "Content-Type" field that theInternet media type of the representation is "image/jpeg", readsthe sequence of octets that make up the representation data, andrenders the image.
This section describes thearchitectural principles and constraints regarding interactionsbetween agents, including such topics as network protocols andinteraction styles, along with interactions between the Web as asystem and the people that make use of it. The fact that the Web isa highly distributed system affects architectural constraints andassumptions about interactions.
Agents may use a URI to access thereferenced resource; this is calleddereferencing the URI. Access maytake many forms, including retrieving a representation of theresource (for instance, by using HTTP GET or HEAD), adding ormodifying a representation of the resource (for instance, by usingHTTP POST or PUT, which in some cases may change the actual stateof the resource if the submitted representations are interpreted asinstructions to that end), and deleting some or all representationsof the resource (for instance, by using HTTP DELETE, which in somecases may result in the deletion of the resource itself).
There may be more than one way toaccess a resource for a given URI; application context determineswhich access method an agent uses. For instance, a browser mightuse HTTP GET to retrieve a representation of a resource, whereas ahypertext link checker might use HTTP HEAD on the same URI simplyto establish whether a representation is available. Some URIschemes set expectations about available access methods, others(such as the URN scheme [RFC2141]) do not. Section 1.2.2 of [URI] discusses the separation of identification andinteraction in more detail. For more information aboutrelationships between multiple access methods and URIaddressability, see the TAG finding"URIs, Addressability, and the use of HTTP GET andPOST".
Although manyURI schemes (§2.4) are named after protocols, thisdoes not imply that use of such a URI will necessarily result inaccess to the resource via the named protocol. Even when an agentuses a URI to retrieve a representation, that access might bethrough gateways, proxies, caches, and name resolution servicesthat are independent of the protocol associated with the schemename.
Many URI schemes define a defaultinteraction protocol for attempting access to the identifiedresource. That interaction protocol is often the basis forallocating identifiers within that scheme, just as "http" URIs aredefined in terms of TCP-based HTTP servers. However, this does notimply that all interaction with such resources is limited to thedefault interaction protocol. For example, information retrievalsystems often make use of proxies to interact with a multitude ofURI schemes, such as HTTP proxies being used to access "ftp" and"wais" resources. Proxies can also to provide enhanced services,such as annotation proxies that combine normal informationretrieval with additional metadata retrieval to provide a seamless,multidimensional view of resources using the same protocols anduser agents as the non-annotated Web. Likewise, future protocolsmay be defined that encompass our current systems, using entirelydifferent interaction mechanisms, without changing the existingidentifier schemes. See also,principle of orthogonal specifications (§5.1).
Dereferencing a URI generallyinvolves a succession of steps as described in multiplespecifications and implemented by the agent. The following exampleillustrates the series of specifications that governs the processwhen a user agent is instructed to follow ahypertext link (§4.4) that is part of an SVGdocument. In this example, the URI is"http://weather.example.com/oaxaca" and the application contextcalls for the user agent to retrieve and render a representation ofthe identified resource.
- Since the URI is part of a hypertext link in an SVG document,the first relevant specification is the SVG 1.1 Recommendation[SVG11].Section 17.1 ofthis specification imports the link semantics defined in XLink 1.0[XLink10]: "The remote resource(the destination for the link) is defined by a URI specified by theXLink
href attribute on the 'a' element."The SVG specification goes on to state that interpretation of ana element involves retrieving a representation of aresource, identified by thehref attribute in theXLink namespace: "By activating these links (by clicking with themouse, through keyboard input, voice commands, etc.), users mayvisit these resources." - The XLink 1.0 [XLink10]specification, which defines the
href attribute insection 5.4, states that "The value of the href attribute must be aURI reference as defined in [IETF RFC 2396], or must result in aURI reference after the escaping procedure described below isapplied." - The URI specification [URI]states that "Each URI begins with a scheme name that refers to aspecification for assigning identifiers within that scheme." TheURI scheme name in this example is "http".
- [IANASchemes] statesthat the "http" scheme is defined by the HTTP/1.1 specification(RFC 2616 [RFC2616], section3.2.2).
- In this SVG context, the agent constructs an HTTP GET request(per section 9.3 of [RFC2616])to retrieve the representation.
- Section 6 of [RFC2616]defines how the server constructs a corresponding response message,including the 'Content-Type' field.
- Section 1.4 of [RFC2616]states "HTTP communication usually takes place over TCP/IPconnections." This example addresses neither that step in theprocess nor other steps such as Domain Name System(DNS) resolution.
- The agent interprets the returned representation according tothe data format specification that corresponds to therepresentation'sInternet Media Type (§3.2) (the value of the HTTP'Content-Type') in the relevant IANA registry [MEDIATYPEREG].
Precisely which representation(s)are retrieved depends on a number of factors, including:
- Whether the URI owner makes available any representations atall;
- Whether the agent making the request has access privileges forthose representations (see the section onlinking and access control (§3.5.2));
- If the URI owner has provided more than one representation (indifferent formats such as HTML, PNG, or RDF; in different languagessuch as English and Spanish; or transformed dynamically accordingto the hardware or software capabilities of the recipient), theresulting representation may depend on negotiation between the useragent and server.
- The time of the request; the world changes over time, sorepresentations of resources are also likely to change overtime.
Assuming that a representation hasbeen successfully retrieved, the expressive power of therepresentation's format will affect how precisely therepresentation provider communicates resource state. If therepresentation communicates the state of the resource inaccurately,this inaccuracy or ambiguity may lead to confusion among usersabout what the resource is. If different users reach differentconclusions about what the resource is, they may interpret this asaURI collision (§2.2.1).Some communities, such as the ones developing the Semantic Web,seek to provide a framework for accurately communicating thesemantics of a resource in a machine readable way. Machine readablesemantics may alleviate some of the ambiguity associated withnatural language descriptions of resources.
Arepresentation is data thatencodes information about resource state. Representations do notnecessarily describe the resource, or portray a likeness of theresource, or represent the resource in other senses of the word"represent".
Representations of a resource maybe sent or received using interaction protocols. These protocols inturn determine the form in which representations are conveyed onthe Web. HTTP, for example, provides for transmission ofrepresentations as octet streams typed using Internet media types[RFC2046].
Just as it is important to reuseexisting URI schemes whenever possible, there are significantbenefits to using media typed octet streams for representationseven in the unusual case where a new URI scheme and associatedprotocol is to be defined. For example, if the Oaxaca weather wereconveyed to Nadia's browser using a protocol other than HTTP, thensoftware to render formats such as text/xhmtl+xml and image/pngwould still be usable if the new protocol supported transmission ofthose types. This is an example of theprinciple of orthogonal specifications (§5.1).
Goodpractice:Reuse representation formats
New protocolscreated for the Web SHOULD transmit representations as octetstreams typed by Internet media types.
The Internet media type mechanismdoes have some limitations. For instance, media type strings do notsupportversioning (§4.2.1)or other parameters. See TAG issuesuriMediaType-9 andmediaTypeManagement-45 which concern aspects ofthe media type mechanism.
The Internet Media Type defines thesyntax and semantics of the fragment identifier (introduced inFragment Identifiers (§2.6)), ifany, that may be used in conjunction with a representation.
Story
In one of his XHTML pages, Dirkcreates a hypertext link to an image that Nadia has published onthe Web. He creates a hypertext link with<ahref="http://www.example.com/images/nadia#hat">Nadia'shat</a>. Emma views Dirk's XHTML page in her Webbrowser and follows the link. The HTML implementation in herbrowser removes the fragment from the URI and requests the image"http://www.example.com/images/nadia". Nadia serves an SVGrepresentation of the image (with Internet media type"image/svg+xml"). Emma's Web browser starts up an SVGimplementation to view the image. It passes it the original URIincluding the fragment, "http://www.example.com/images/nadia#hat"to this implementation, causing a view of the hat to be displayedrather than the complete image.
Note that the HTML implementationin Emma's browser did not need tounderstand the syntax orsemantics of the SVG fragment (nor does the SVG implementationhave to understand HTML, WebCGM, RDF ... fragment syntax orsemantics; it merely had to recognize the # delimiter from the URIsyntax [URI] and remove the fragment when accessing the resource).Thisorthogonality(§5.1) is an important feature of Web architecture; it is whatenabled Emma's browser to provide a useful service withoutrequiring an upgrade.
The semantics of a fragmentidentifier are defined by the set of representations that mightresult from a retrieval action on the primary resource. Thefragment's format and resolution are therefore dependent on thetype of a potentially retrieved representation, even though such aretrieval is only performed if the URI is dereferenced. If no suchrepresentation exists, then the semantics of the fragment areconsidered unknown and, effectively, unconstrained. Fragmentidentifier semantics are orthogonal to URI schemes and thus cannotbe redefined by URI scheme specifications.
Interpretation of the fragmentidentifier is performed solely by the agent that dereferences aURI; the fragment identifier is not passed to other systems duringthe process of retrieval. This means that some intermediaries inWeb architecture (such as proxies) have no interaction withfragment identifiers and that redirection (in HTTP [RFC2616], for example) does not accountfor fragments.
Content negotiation refers to thepractice of making available multiple representations via the sameURI. Negotiation between the requesting agent and the serverdetermines which representation is served (usually with the goal ofserving the "best" representation a receiving agent can process).HTTP is an example of a protocol that enables representationproviders to use content negotiation.
Individual data formats may definetheir own rules for use of the fragment identifier syntax forspecifying different types of subsets, views, or externalreferences that are identifiable as secondary resources by thatmedia type. Therefore, representation providers must manage contentnegotiation carefully when used with a URI that contains a fragmentidentifier. Consider an example where the owner of the URI"http://weather.example.com/oaxaca/map#zicatela" uses contentnegotiation to serve two representations of the identifiedresource. Three situations can arise:
- The interpretation of "zicatela" is defined consistently byboth data format specifications. The representation providerdecides when definitions of fragment identifier semantics are aresufficiently consistent.
- The interpretation of "zicatela" is defined inconsistently bythe data format specifications.
- The interpretation of "zicatela" is defined in one data formatspecification but not the other.
The first situation—consistentsemantics—poses no problem.
The second case is a servermanagement error: representation providers must not use contentnegotiation to serve representation formats that have inconsistentfragment identifier semantics. This situation also leads toURI collision(§2.2.1).
The third case is not a servermanagement error. It is a means by which the Web can grow. Becausethe Web is a distributed system in which formats and agents aredeployed in a non-uniform manner, Web architecture does notconstrain authors to only use "lowest common denominator" formats.Content authors may take advantage of new data formats while stillensuring reasonable backward-compatibility for agents that do notyet implement them.
In case three, behavior by thereceiving agent should vary depending on whether the negotiatedformat defines fragment identifier semantics. When a received dataformat does not define fragment identifier semantics, the agentshould not performsilent error recovery unless the user has given consent;see [CUAP] for additionalsuggested agent behavior in this case.
See related TAG issueRDFinXHTML-35.
Successful communication betweentwo parties depends on a reasonably shared understanding of thesemantics of exchanged messages, both data and metadata. At times,there may be inconsistencies between a message sender's data andmetadata. Examples, observed in practice, of inconsistenciesbetween representation data and metadata include:
- The actual character encoding of a representation (e.g.,"iso-8859-1", specified by the
encoding attribute inan XML declaration) is inconsistent with the charset parameter inthe representation metadata (e.g., "utf-8", specified by the'Content-Type' field in an HTTP header). - Thenamespace(§4.5.3) of the root element of XML representation data (e.g.,as specified by the "xmlns" attribute) is inconsistent with thevalue of the 'Content-Type' field in an HTTP header.
On the other hand, there is noinconsistency in serving HTML content with the media type"text/plain", for example, as this combination is licensed byspecifications.
Receiving agents should detectprotocol inconsistencies and perform propererror recovery.
Thus, for example, if the partiesresponsible for "weather.example.com" mistakenly label thesatellite photo of Oaxaca as "image/gif" instead of "image/jpeg",and if Nadia's browser detects a problem, Nadia's browser must notignore the problem (e.g., by simply rendering the JPEG image)without Nadia's consent. Nadia's browser can notify Nadia of theproblem or notify Nadia and take corrective action.
Furthermore, representationproviders can help reduce the risk of inconsistencies throughcareful assignment of representation metadata (especially thatwhich applies across representations). The section onmedia types for XML (§4.5.7)presents an example of reducing the risk of error by providing nometadata about character encoding when serving XML.
The accuracy of metadata relies onthe server administrators, the authors of representations, and thesoftware that they use. Practically, the capabilities of the toolsand the social relationships may be the limiting factors.
The accuracy of these and othermetadata fields is just as important for dynamic Web resources,where a little bit of thought and programming can often ensurecorrect metadata for a huge number of resources.
Often there is a separation ofcontrol between the users who create representations of resourcesand the server managers who maintain the Web site software. Giventhat it is generally the Web site software that provides themetadata associated with a resource, it follows that coordinationbetween the server managers and content creators is required.
Goodpractice:Metadataassociation
Server managersSHOULD allow representation creators to control the metadataassociated with their representations.
In particular, content creatorsneed to be able to control the content type (for extensibility) andthe character encoding (for proper internationalization).
The TAG finding"Authoritative Metadata" discusses in more detailhow to handle data/metadata inconsistency and how serverconfiguration can be used to avoid it.
Nadia's retrieval of weatherinformation (an example of a read-only query or lookup) qualifiesas a "safe" interaction; asafe interaction is one wherethe agent does not incur any obligation beyond the interaction. Anagent may incur an obligation through other means (such as bysigning a contract). If an agent does not have an obligation beforea safe interaction, it does not have that obligationafterwards.
Other Web interactions resembleorders more than queries. Theseunsafe interactions maycause a change to the state of a resource and the user may be heldresponsible for the consequences of these interactions. Unsafeinteractions include subscribing to a newsletter, posting to alist, or modifying a database.Note: In thiscontext, the word "unsafe" does not necessarily mean "dangerous";the term "safe" is used in section 9.1.1 of [RFC2616] and "unsafe" is the natural opposite.
Story
Nadia decides to book a vacation toOaxaca at "booking.example.com." She enters data into a series ofonline forms and is ultimately asked for credit card information topurchase the airline tickets. She provides this information inanother form. When she presses the "Purchase" button, her browseropens another network connection to the server at"booking.example.com" and sends a message composed of form datausing the POST method. This is anunsafe interaction; Nadia wishes to change thestate of the system by exchanging money for airline tickets.
The server reads the POST request,and after performing the booking transaction returns a message toNadia's browser that contains a representation of the results ofNadia's request. The representation data is in XHTML so that it canbe saved or printed out for Nadia's records.
Note that neither the datatransmitted with the POST nor the data received in the responsenecessarily correspond to any resource identified by a URI.
Safe interactions are importantbecause these are interactions where users can browse withconfidence and where agents (including search engines and browsersthat pre-cache data for the user) can follow hypertext linkssafely. Users (or agents acting on their behalf) do not committhemselves to anything by querying a resource or following ahypertext link.
Principle:Safe retrieval
Agents do notincur obligations by retrieving a representation.
For instance, it is incorrect topublish a URI that, when followed as part of a hypertext link,subscribes a user to a mailing list. Remember that search enginesmay follow such hypertext links.
The fact that HTTP GET, the accessmethod most often used when following a hypertext link, is safedoes not imply that all safe interactions must be done through HTTPGET. At times, there may be good reasons (such as confidentialityrequirements or practical limits on URI length) to conduct anotherwise safe operation using a mechanism generally reserved forunsafe operations (e.g., HTTP POST).
For more information about safe andunsafe operations using HTTP GET and POST, and handling securityconcerns around the use of HTTP GET, see the TAG finding"URIs, Addressability, and the use of HTTP GET andPOST".
Story
Nadia pays for her airline ticketsonline (through a POST interaction as described above). Shereceives a Web page with confirmation information and wishes tobookmark it so that she can refer to it when she calculates herexpenses. Although Nadia can print out the results, or save them toa file, she would also like to bookmark them.
Transaction requests and resultsare valuable resources, and like all valuable resources, it isuseful to be able to refer to them with apersistent URI (§3.5.1).However, in practice, Nadia cannot bookmark her commitment to pay(expressed via the POST request) or the airline company'sacknowledgment and commitment to provide her with a flight(expressed via the response to the POST).
There are ways to providepersistent URIs for transaction requests and their results. Fortransaction requests, user agents can provide an interface formanaging transactions where the user agent has incurred anobligation on behalf of the user. For transaction results, HTTPallows representation providers to associate a URI with the resultsof an HTTP POST request using the "Content-Location" header(described in section 14.14 of [RFC2616]).
Story
Since Nadia finds the Oaxacaweather site useful, she emails a review to her friend Dirkrecommending that he check out 'http://weather.example.com/oaxaca'.Dirk clicks on the resulting hypertext link in the email hereceives and is frustrated by a 404 (not found). Dirk tries againthe next day and receives a representation with "news" that istwo-weeks old. He tries one more time the next day only to receivea representation that claims that the weather in Oaxaca is sunny,even though his friends in Oaxaca tell him by phone that in fact itis raining. Dirk and Nadia conclude that the URI owners areunreliable or unpredictable. Although the URI owner has chosen theWeb as a communication medium, the owner has lost two customers dueto ineffective representation management.
A URI owner may supply zero or moreauthoritative representations of the resource identified by thatURI. There is a benefit to the community in providingrepresentations.
For example, owners of XMLnamespace URIs should use them to identify anamespace document(§4.5.4).
Just because representations areavailable does not mean that it is always desirable to retrievethem. In fact, in some cases the opposite is true.
Principle:Reference does not implydereference
An applicationdeveloper or specification author SHOULD NOT require networkedretrieval of representations each time they are referenced.
Dereferencing a URI has a(potentially significant) cost in computing and bandwidthresources, may have security implications, and may imposesignificant latency on the dereferencing application. DereferencingURIs should be avoided except when necessary.
The following sections discuss someaspects of representation management, including promotingURI persistence (§3.5.1),managingaccess to resources(§3.5.2), andsupporting navigation (§3.5.3).
As is the case with many humaninteractions, confidence in interactions via the Web depends onstability and predictability. For an information resource,persistence depends on the consistency of representations. Therepresentation provider decides when representations aresufficiently consistent (although that determination generallytakes user expectations into account).
Although persistence in this caseis observable as a result of representation retrieval, the termURIpersistence is used to describe the desirable propertythat, once associated with a resource, a URI should continueindefinitely to refer to that resource.
Goodpractice:Consistent representation
A URI ownerSHOULD provide representations of the identified resourceconsistently and predictably.
URI persistence is a matter ofpolicy and commitment on the part of theURI owner. The choice of a particular URI schemeprovides no guarantee that those URIs will be persistent or thatthey will not be persistent.
HTTP [RFC2616] has been designed to help manage URIpersistence. For example, HTTP redirection (using the 3xx responsecodes) permits servers to tell an agent that further action needsto be taken by the agent in order to fulfill the request (forexample, a new URI is associated with the resource).
In addition,content negotiation also promotes consistency, asa site manager is not required to define new URIs when addingsupport for a new format specification. Protocols that do notsupport content negotiation (such as FTP) require a new identifierwhen a new data format is introduced. Improper use of contentnegotiation can lead to inconsistent representations.
For more discussion about URIpersistence, see [Cool].
It is reasonable to limit access toa resource (for commercial or security reasons, for example), butmerely identifying the resource is like referring to a book bytitle. In exceptional circumstances, people may have agreed to keeptitles or URIs confidential (for example, a book author and apublisher may agree to keep the URI of page containing additionalmaterial secret until after the book is published), otherwise theyare free to exchange them.
As an analogy: The owners of abuilding might have a policy that the public may only enter thebuilding via the main front door, and only during business hours.People who work in the building and who make deliveries to it mightuse other doors as appropriate. Such a policy would be enforced bya combination of security personnel and mechanical devices such aslocks and pass-cards. One would not enforce this policy by hidingsome of the building entrances, nor by requesting legislationrequiring the use of the front door and forbidding anyone to revealthe fact that there are other doors to the building.
Story
Nadia sends to Dirk the URI of thecurrent article she is reading. With his browser, Dirk follows thehypertext link and is asked to enter his subscriber username andpassword. Since Dirk is also a subscriber to services provided by"weather.example.com," he can access the same information as Nadia.Thus, the authority for "weather.example.com" can limit access toauthorized parties and still provide the benefits of URIs.
The Web provides several mechanismsto control access to resources; these mechanisms do not rely onhiding or suppressing URIs for those resources. For moreinformation, see the TAG finding"'Deep Linking' in the World Wide Web".
It is a strength of WebArchitecture that links can be made and shared; a user who hasfound an interesting part of the Web can share this experience justby republishing a URI.
Story
Nadia and Dirk want to visit theMuseum of Weather Forecasting in Oaxaca. Nadia goes to"http://maps.example.com", locates the museum, and mails the URI"http://maps.example.com/oaxaca?lat=17.065;lon=-96.716;scale=6" toDirk. Dirk goes to "http://mymaps.example.com", locates the museum,and mails the URI"http://mymaps.example.com/geo?sessionID=765345;userID=Dirk" toNadia. Dirk reads Nadia's email and is able to follow the link tothe map. Nadia reads Dirk's email, follows the link, and receivesan error message 'No such session/user'. Nadia has to start againfrom "http://mymaps.example.com" and find the museum location oncemore.
For resources that are generated ondemand, machine generation of URIs is common. For resources thatmight usefully be bookmarked for later perusal, or shared withothers, server managers should avoid needlessly restricting thereusability of such URIs. If the intention is to restrictinformation to a particular user, as might be the case in a homebanking application for example, designers should use appropriateaccess control (§3.5.2)mechanisms.
Interactions conducted with HTTPPOST (where HTTP GET could have been used) also limit navigationpossibilities. The user cannot create a bookmark or share the URIbecause HTTP POST transactions do not typically result in adifferent URI as the user interacts with the site.
There remain open questionsregarding Web interactions. The TAG expects future versions of thisdocument to address in more detail the relationship between thearchitecture described herein,Web Services, peer-to-peer systems, instantmessaging systems (such as [RFC3920]), streaming audio (such as RTSP [RFC2326]), and voice-over-IP (such asSIP [RFC3261]).
A data format specification (forexample, for XHTML, RDF/XML, SMIL, XLink, CSS, and PNG) embodies anagreement on the correct interpretation ofrepresentation data. Thefirst data format used on the Web was HTML. Since then, dataformats have grown in number. Web architecture does not constrainwhich data formats content providers can use. This flexibility isimportant because there is constant evolution in applications,resulting in new data formats and refinements of existing formats.Although Web architecture allows for the deployment of new dataformats, the creation and deployment of new formats (and agentsable to handle them) is expensive. Thus, before inventing a newdata format (or "meta" format such as XML), designers shouldcarefully consider re-using one that is already available.
For a data format to be usefullyinteroperable between two parties, the parties must agree (to areasonable extent) about its syntax and semantics. Sharedunderstanding of a data format promotes interoperability but doesnot imply constraints on usage; for instance, a sender of datacannot count on being able to constrain the behavior of a datareceiver.
Below we describe somecharacteristics of a data format that facilitate integration intoWeb architecture. This document does not address generallybeneficial characteristics of a specification such as readability,simplicity, attention to programmer goals, attention to user needs,accessibility, nor internationalization. The section onarchitectural specifications (§7.1)includes references to additional format specificationguidelines.
Binary data formats are those inwhich portions of the data are encoded for direct use by computerprocessors, for example 32 bit little-endian two's-complement and64 bit IEEE double-precision floating-point. The portions of dataso represented include numeric values, pointers, and compresseddata of all sorts.
A textual data format is one inwhich the data is specified in a defined encoding as a sequence ofcharacters. HTML, Internet e-mail, and allXML-based formats (§4.5) are textual.Increasingly, internationalized textual data formats refer to theUnicode repertoire [UNICODE]for character definitions.
If a data format is textual, asdefined in this section, that does not imply that it should beserved with a media type beginning with "text/". Although XML-basedformats are textual, many XML-based formats do not consistprimarily of phrases in natural language. See the section onmedia types for XML(§4.5.7) for issues that arise when "text/" is used inconjunction with an XML-based format.
In principle, all data can berepresented using textual formats. In practice, some types ofcontent (e.g., audio and video) are generally represented usingbinary formats.
The trade-offs between binary andtextual data formats are complex and application-dependent. Binaryformats can be substantially more compact, particularly for complexpointer-rich data structures. Also, they can be consumed morerapidly by agents in those cases where they can be loaded intomemory and used with little or no conversion. Note, however, thatsuch cases are relatively uncommon as such direct use may open thedoor to security issues that can only practically be addressed byexamining every aspect of the data structure in detail.
Textual formats are usually moreportable and interoperable. Textual formats also have theconsiderable advantage that they can be directly read by humanbeings (and understood, given sufficient documentation). This cansimplify the tasks of creating and maintaining software, and allowthe direct intervention of humans in the processing chain withoutrecourse to tools more complex than the ubiquitous text editor.Finally, it simplifies the necessary human task of learning aboutnew data formats; this is called the "view source" effect.
It is important to emphasize thatintuition as to such matters as data size and processing speed isnot a reliable guide in data format design; quantitative studiesare essential to a correct understanding of the trade-offs.Therefore, designers of a data format specification should make aconsidered choice between binary and textual format design.
See TAG issuebinaryXML-30.
In a perfect world, languagedesigners would invent languages that perfectly met therequirements presented to them, the requirements would be a perfectmodel of the world, they would never change over time, and allimplementations would be perfectly interoperable because thespecifications would have no variability.
In the real world, languagedesigners imperfectly address the requirements as they interpretthem, the requirements inaccurately model the world, conflictingrequirements are presented, and they change over time. As a result,designers negotiate with users, make compromises, and oftenintroduce extensibility mechanisms so that it is possible to workaround problems in the short term. In the long term, they producemultiple versions of their languages, as the problem, and theirunderstanding of it, evolve. The resulting variability inspecifications, languages, and implementations introducesinteroperability costs.
Extensibility and versioning arestrategies to help manage the natural evolution of information onthe Web and technologies used to represent that information. Formore information about how these strategies introduce variabilityand how that variability impacts interoperability, seeVariability in Specifications.
See TAG issueXMLVersioning-41, which concerns good practices fordesigning extensible XML languages and for handling versioning. Seealso "Web Architecture: Extensible Languages" [EXTLANG].
There is typically a (long)transition period during which multiple versions of a format,protocol, or agent are simultaneously in use.
Goodpractice:Version information
A data formatspecification SHOULD provide for version information.
Story
Nadia and Dirk are designing an XMLdata format to encode data about the film industry. They providefor extensibility by using XML namespaces and creating a schemathat allows the inclusion, in certain places, of elements from anynamespace. When they revise their format, Nadia proposes a newoptionallang attribute on thefilmelement. Dirk feels that such a change requires them to assign anew namespace name, which might require changes to deployedsoftware. Nadia explains to Dirk that their choice of extensibilitystrategy in conjunction with their namespace policy allows certainchanges that do not affect conformance of existing content andsoftware, and thus no change to the namespace identifier isrequired. They chose this policy to help them meet their goals ofreducing the cost of change.
Dirk and Nadia have chosen aparticular namespace change policy that allows them to avoidchanging the namespace name whenever they make changes that do notaffect conformance of deployed content and software. They mighthave chosen a different policy, for example that any new element orattribute has to belong to a namespace other than the original one.Whatever the chosen policy, it should set clear expectations forusers of the format.
In general, changing the namespacename of an element completely changes the element name. If "a" and"b" are bound to two different URIs,a:element andb:element are as distinct asa:eieio anda:xyzzy. Practically speaking, this means thatdeployed applications will have to be upgraded in order torecognize the new language; the cost of this upgrade may be veryhigh.
It follows that there aresignificant tradeoffs to be considered when deciding on a namespacechange policy. If a vocabulary has no extensibility points (thatis, if it does not allow elements or attributes from foreignnamespaces or have a mechanism for dealing with unrecognized namesfrom the same namespace), it may be absolutely necessary to changethe namespace name. Languages that allow some form of extensibilitywithout requiring a change to the namespace name are more likely toevolve gracefully.
Goodpractice:Namespace policy
An XML formatspecification SHOULD include information about change policies forXML namespaces.
As an example of a change policydesigned to reflect the variable stability of a namespace, considertheW3Cnamespace policy for documents on the W3C Recommendation track.The policy sets expectations that the Working Group responsible forthe namespace may modify it in any way until a certain point in theprocess ("Candidate Recommendation") at which point W3C constrainsthe set of possible changes to the namespace in order to promotestable implementations.
Note that since namespace names areURIs, the owner of a namespace URI has the authority to decide thenamespace change policy.
Requirements change over time.Successful technologies are adopted and adapted by new users.Designers can facilitate the transition process by making carefulchoices about extensibility during the design of a language orprotocol specification.
In making these choices, thedesigners must weigh the trade-offs between extensibility,simplicity, and variability. A language without extensibilitymechanisms may be simpler and less variable, improving initialinteroperability. However, it's likely that changes to thatlanguage will be more difficult, possibly more complex and morevariable, than if the initial design had provided such mechanisms.This may decrease interoperability over the long term.
Goodpractice:Extensibility mechanisms
A specificationSHOULD provide mechanisms that allow any party to createextensions.
Extensibility introducesvariability which has an impact on interoperability. However,languages that have no extensibility mechanisms may be extended inad hoc ways that impact interoperability as well. One key criterionof the mechanisms provided by language designers is that they allowthe extended languages to remain in conformance with the originalspecification, increasing the likelihood of interoperability.
Application needs determine themost appropriate extension strategy for a specification. Forexample, applications designed to operate in closed environmentsmay allow specification designers to define a versioning strategythat would be impractical at the scale of the Web.
Goodpractice:Unknown extensions
A specificationSHOULD specify agent behavior in the face of unrecognizedextensions.
Two strategies have emerged asbeing particularly useful:
- "Must ignore": The agent ignores any content it does notrecognize.
- "Must understand": The agent treats unrecognized markup as anerror condition.
A powerful design approach is forthe language to allow either form of extension, but to distinguishexplicitly between them in the syntax.
Additional strategies includeprompting the user for more input and automatically retrieving datafrom available hypertext links. More complex strategies are alsopossible, including mixing strategies. For instance, a language caninclude mechanisms for overriding standard behavior. Thus, a dataformat can specify "must ignore" semantics but also allow forextensions that override that semantics in light of applicationneeds (for instance, with "must understand" semantics for aparticular extension).
Extensibility is not free.Providing hooks for extensibility is one of many requirements to befactored into the costs of language design. Experience suggeststhat the long term benefits of a well-designed extensibilitymechanism generally outweigh the costs.
See “D.3Extensibility and Extensions” in [QA].
Many modern data format includemechanisms for composition. For example:
- It is possible to embed text comments in some image formats,such as JPEG/JFIF. Although these comments are embedded in thecontaining data, they are not intended to affect the display of theimage.
- There are container formats such as SOAP which fully expectcontent from multiple namespaces but which provide an overallsemantic relationship of message envelope and payload.
- The semantics of combining RDF documents containing multiplevocabularies are well-defined.
In principle, these relationshipscan be mixed and nested arbitrarily. A SOAP message, for example,can contain an SVG image that contains an RDF comment which refersto a vocabulary of terms for describing the image.
Note however, that for general XMLthere is no semantic model that defines the interactions within XMLdocuments with elements and/or attributes from a variety ofnamespaces. Each application must define how namespaces interactand what effect the namespace of an element has on the element'sancestors, siblings, and descendants.
See TAG issuesmixedUIXMLNamespace-33 (concerning the meaning ofa document composed of content in multiple namespaces),xmlFunctions-34 (concerning one approach for managingXML transformation and composability), andRDFinXHTML-35 (concerning the interpretation of RDF whenembedded in an XHTML document).
The Web is a heterogeneousenvironment where a wide variety of agents provide access tocontent to users with a wide variety of capabilities. It is goodpractice for authors to create content that can reach the widestpossible audience, including users with graphical desktopcomputers, hand-held devices and mobile phones, users withdisabilities who may require speech synthesizers, and devices notyet imagined. Furthermore, authors cannot predict in some cases howan agent will display or process their content. Experience showsthat the separation of content, presentation, and interactionpromotes the reuse and device-independence of content; this followsfrom theprinciple oforthogonal specifications (§5.1).
This separation also facilitatesreuse of authored source content across multiple delivery contexts.Sometimes, functional user experiences suited to any deliverycontext can be generated by using an adaptation process applied toa representation that does not depend on the access mechanism. Formore information about principles of device-independence, see[DIPRINCIPLES].
Note that when content,presentation, and interaction are separated by design, agents needto recombine them. There is a recombination spectrum, with "clientdoes all" at one end and "server does all" at the other.
There are advantages to eachapproach. For instance when a client (such as a mobile phone)communicates device capabilities to the server (for example, usingCC/PP), the server can tailor the delivered content to fit thatclient. The server can, for example, enable faster downloads byadjusting links to refer to lower resolution images, smaller videoor no video at all. Similarly, if the content has been authoredwith multiple branches, the server can remove unused branchesbefore delivery. In addition, by tailoring the content to match thecharacteristics of a target client, the server can help reduceclient side computation. However, specializing content in thismanner reduces caching efficiency.
On the other hand, designingcontent that that can be recombined on the client also tends tomake that content applicable to a wider range of devices. Thisdesign also improves caching efficiency and offers users morepresentation options. Media-dependent style sheets can be used totailor the content on the client side to particular groups oftarget devices. For textual content with a regular and repeatingstructure, the combined size of the text content plus the stylesheet is typically less than that of fully recombined content; thesavings improve further if the style sheet is reused by otherpages.
In practice a combination of bothapproaches is often used. The design decision about where on thisspectrum an application should be placed depends on the power onthe client, the power and the load on the server, and the bandwidthof the medium that connects them. If the number of possible clientsis unbounded, the application will scale better if more computationis pushed to the client.
Of course, it may not be desirableto reach the widest possible audience. Designers should considerappropriate technologies, such as encryption andaccess control (§3.5.2), for limitingthe audience.
Some data formats are designed todescribe presentation (including SVG and XSL Formatting Objects).Data formats such as these demonstrate that one can only separatecontent from presentation (or interaction) so far; at some point itbecomes necessary to talk about presentation. Per the principle oforthogonal specifications(§5.1) these data formats shouldonly addresspresentation issues.
See the TAG issuesformattingProperties-19 (concerninginteroperability in the case of formatting properties and names)andcontentPresentation-26 (concerning the separationof semantic and presentational markup).
A defining characteristic of theWeb is that it allows embedded references to other resources viaURIs. The simplicity of creating hypertext links using absoluteURIs (<a href="http://www.example.com/foo">) andrelative URI references (<a href="foo"> and<a href="foo#anchor">) is partly (perhapslargely) responsible for the success of the hypertext Web as weknow it today.
When a representation of oneresource contains a reference to another resource, expressed with aURI identifying that other resource, this constitutes alink between the tworesources. Additional metadata may also form part of the link (see[XLink10], for example).Note: In this document, the term "link" generallymeans "relationship", not "physical connection".
Goodpractice:Link identification
A specificationSHOULD provide ways to identify links to other resources, includingto secondary resources (via fragment identifiers).
Formats that allow content authorsto use URIs instead of local identifiers promote the networkeffect: the value of these formats grows with the size of thedeployed Web.
Goodpractice:Weblinking
A specificationSHOULD allow Web-wide linking, not just internal documentlinking.
Goodpractice:Generic URIs
A specificationSHOULD allow content authors to use URIs without constraining themto a limited set of URI schemes.
What agents do with a hypertextlink is not constrained by Web architecture and may depend onapplication context. Users of hypertext links expect to be able tonavigate among representations by following links.
Goodpractice:Hypertext links
A data formatSHOULD incorporate hypertext links if hypertext is the expecteduser interface paradigm.
Data formats that do not allowcontent authors to create hypertext links lead to the creation of"terminal nodes" on the Web.
Links are commonly expressed usingURI references (definedin section 4.2 of [URI]), which maybe combined with a base URI to yield a usable URI. Section 5.1 of[URI] explains different ways toestablish a base URI for a resource and establishes a precedenceamong them. For instance, the base URI may be a URI for theresource, or specified in a representation (see thebase elements provided by HTML and XML, and the HTTP'Content-Location' header). See also the section onlinks in XML(§4.5.2).
Agents resolve a URI referencebefore using the resulting URI to interact with another agent. URIreferences help in content management by allowing content authorsto design a representation locally, i.e., without concern for whichglobal identifier may later be used to refer to the associatedresource.
Many data formats areXML-based, that is to saythey conform to the syntax rules defined in the XML specification[XML10] or [XML11]. This section discusses issues that arespecific to such formats. Anyone seeking guidance in this area isurged to consult the "Guidelines For the Use of XML in IETFProtocols"[IETFXML], whichcontains a thorough discussion of the considerations that governwhether or not XML ought to be used, as well as specific guidelineson how it ought to be used. While it is directed at Internetapplications with specific reference to protocols, the discussionis generally applicable to Web scenarios as well.
The discussion here should be seenas ancillary to the content of[IETFXML]. Refer also to "XML Accessibility Guidelines"[XAG] for help designing XMLformats that lower barriers to Web accessibility for people withdisabilities.
XML defines textual data formatsthat are naturally suited to describing data objects which arehierarchical and processed in a chosen sequence. It is widely, butnot universally, applicable for data formats; an audio or videoformat, for example, is unlikely to be well suited to expression inXML. Design constraints that would suggest the use of XMLinclude:
- Requirement for a hierarchical structure.
- Need for a wide range of tools on a variety of platforms.
- Need for data that can outlive the applications that currentlyprocess it.
- Ability to support internationalization in a self-describingway that makes confusion over coding options unlikely.
- Early detection of encoding errors with no requirement to "workaround" such errors.
- A high proportion of human-readable textual content.
- Potential composition of the data format with other XML-encodedformats.
- Desire for data easily parsed by both humans and machines.
- Desire for vocabularies that can be invented in a distributedmanner and combined flexibly.
Sophisticated linking mechanismshave been invented for XML formats. XPointer allows links toaddress content that does not have an explicit, named anchor.[XLink] is an appropriatespecification for representing links inhypertext (§4.4) XML applications. XLink allows links tohave multiple ends and to be expressed either inline or in "linkbases" stored external to any or all of the resources identified bythe links it contains.
Designers of XML-based formats mayconsider using XLink and, for defining fragment identifier syntax,using the XPointer framework and XPointer element() Schemes.
XLink is not the only linkingdesign that has been proposed for XML, nor is it universallyaccepted as a good design. See also TAG issuexlinkScope-23.
The purpose of an XML namespace(defined in [XMLNS]) is to allowthe deployment of XML vocabularies (in which element and attributenames are defined) in a global environment and to reduce the riskof name collisions in a given document when vocabularies arecombined. For example, the MathML and SVG specifications bothdefine theset element. Although XML data fromdifferent formats such as MathML and SVG can be combined in asingle document, in this case there could be ambiguity about whichset element was intended. XML namespaces reduce therisk of name collisions by taking advantage of existing systems forallocating globally scoped names: the URI system (see also thesection onURI allocation (§2.2.2)). When using XML namespaces,each local name in an XML vocabulary is paired with a URI (calledthe namespace URI) to distinguish the local name from local namesin other vocabularies.
The use of URIs confers additionalbenefits. First, each URI/local name pair can be mapped to anotherURI, grounding the terms of the vocabulary in the Web. These termsmay be important resources and thus it is appropriate to be able toassociate URIs with them.
[RDFXML] uses simple concatenation of the namespace URIand the local name to create a URI for the identified term. Othermappings are likely to be more suitable for hierarchicalnamespaces; see the related TAG issueabstractComponentRefs-37.
Designers of XML-based data formatswho declare namespaces thus make it possible to reuse those dataformats and combine them in novel ways not yet imagined. Failure todeclare namespaces makes such reuse more difficult, evenimpractical in some cases.
Goodpractice:Namespace adoption
A specificationthat establishes an XML vocabulary SHOULD place all element namesand global attribute names in a namespace.
Attributes are always scoped by theelement on which they appear. An attribute that is "global," thatis, one that might meaningfully appear on elements of many types,including elements in other namespaces, should be explicitly placedin a namespace. Local attributes, ones associated with only aparticular element type, need not be included in a namespace sincetheir meaning will always be clear from the context provided bythat element.
Thetype attributefrom the W3C XML Schema Instance namespace"http://www.w3.org/2001/XMLSchema-instance" ([XMLSCHEMA], section 4.3.2) is an example of aglobal attribute. It can be used by authors of any vocabulary tomake an assertion in instance data about the type of the element onwhich it appears. As a global attribute, it must always bequalified. Theframe attribute on an HTML table is anexample of a local attribute. There is no value in placing thatattribute in a namespace since the attribute is unlikely to beuseful on an element other than an HTML table.
Applications that rely on DTDprocessing must impose additional constraints on the use ofnamespaces. DTDs perform validation based on the lexical form ofthe element and attribute names in the document. This makesprefixes syntactically significant in ways that are not anticipatedby [XMLNS].
Story
Nadia receives representation datafrom "weather.example.com" in an unfamiliar data format. She knowsenough about XML to recognize which XML namespace the elementsbelong to. Since the namespace is identified by the URI"http://weather.example.com/2003/format", she asks her browser toretrieve a representation of the identified resource. She gets backsome useful data that allows her to learn more about the dataformat. Nadia's browser may also be able to perform some operationsautomatically (i.e., unattended by a human overseer) given datathat has been optimized for software agents. For example, herbrowser might, on Nadia's behalf, download additional agents toprocess and render the format.
Another benefit of using URIs tobuild XML namespaces is that the namespace URI can be used toidentify an information resource that contains useful information,machine-usable and/or human-usable, about terms in the namespace.This type of information resource is called anamespace document. When a namespaceURI owner provides a namespace document, it is authoritative forthe namespace.
There are many reasons to provide anamespace document. A person might want to:
- understand the purpose of the namespace,
- learn how to use the markup vocabulary in the namespace,
- find out who controls it and associated policies,
- request authority to access schemas or collateral materialabout it, or
- report a bug or situation that could be considered an error insome collateral material.
A processor might want to:
- retrieve a schema, for validation,
- retrieve a style sheet, for presentation, or
- retrieve ontologies, for making inferences.
In general, there is no establishedbest practice for creating representations of a namespace document;application expectations will influence what data format or formatsare used. Application expectations will also influence whetherrelevant information appears directly in a representation or isreferenced from it.
Goodpractice:Namespacedocuments
The owner of anXML namespace name SHOULD make available material intended forpeople to read and material optimized for software agents in orderto meet the needs of those who will use the namespacevocabulary.
For example, the following areexamples of data formats for namespace documents: [OWL10], [RDDL],[XMLSCHEMA], and [XHTML11]. Each of these formats meetsdifferent requirements described above for satisfying the needs ofan agent that wants more information about the namespace. Note,however, issues related tofragment identifiers and content negotiation (§3.2.2) ifcontent negotiation is used.
See TAG issuesnamespaceDocument-8 (concerning desired characteristicsof namespace documents) andabstractComponentRefs-37 (concerning the use offragment identifiers with namespace names to identify abstractcomponents).
Section 3 of "Namespaces in XML"[XMLNS] provides a syntacticconstruct known as a QName for the compact expression of qualifiednames in XML documents. A qualified name is a pair consisting of aURI, which names a namespace, and a local name placed within thatnamespace. "Namespaces in XML" provides for the use of QNames asnames for XML elements and attributes.
Other specifications, starting with[XSLT10], have employed the ideaof using QNames in contexts other than element and attribute names,for example in attribute values and in element content. However,general XML processors cannot reliably recognize QNames as suchwhen they are used in attribute values and in element content; forexample, the syntax of QNames overlaps with that of URIs.Experience has also revealed other limitations to QNames, such aslosing namespace bindings after XML canonicalization.
For more information, see the TAGfinding"UsingQNames as Identifiers in Content".
Because QNames are compact, somespecification designers have adopted the same syntax as a means ofidentifying resources. Though convenient as a shorthand notation,this usage has a cost. There is no single, accepted way to converta QName into a URI or vice versa. Although QNames are convenient,they do not replace the URI as the identification system of theWeb. The use of QNames to identify Web resources without providinga mapping to URIs is inconsistent with Web architecture.
Goodpractice:QName Mapping
A specificationin which QNames serve as resource identifiers MUST provide amapping to URIs.
SeeXML namespaces (§4.5.3) for examples of somemapping strategies.
See also TAG issuesrdfmsQnameUriMapping-6 (concerning the mapping ofQNames to URIs),qnameAsId-18 (concerning the use of QNames asidentifiers in XML content), andabstractComponentRefs-37 (concerning the use offragment identifiers with namespace names to identify abstractcomponents).
Consider the following fragment ofXML:<section name="foo">. Does thesection element have what the XML Recommendationrefers to as the IDfoo (i.e., "foo" must not appearin the surrounding XML document more than once)? One cannot answerthis question by examining the element and its attributes alone. InXML, the quality of "being an ID" is associated with the type of anattribute, not its name. Finding the IDs in a document requiresadditional processing.
- Processing the document with a processor that recognizes DTDattribute list declarations (in the external or internal subset)might reveal a declaration that identifies the
nameattribute as an ID.Note: This processing is notnecessarily part of validation. A non-validating, DTD-awareprocessor can recognize IDs. - Processing the document with a W3C XML schema might reveal anelement declaration that identifies the
name attributeas an W3C XML SchemaID. - In practice, processing the document with another schemalanguage, such as RELAX NG [RELAXNG], might reveal the attributes declared to be ofID in the XML Schema sense. Many modern specifications beginprocessing XML at the Infoset [INFOSET] level and do not specify normatively how anInfoset is constructed. For those specifications, any process thatestablishes the ID type in the Infoset (and Post Schema ValidationInfoset (PSVI) defined in [XMLSCHEMA]) may usefully identify the attributesof type ID.
- In practice, applications may have independent means (such asthose defined in the XPointer specification, [XPTRFR]section 3.2) of locating identifiers inside adocument.
To further complicate matters, DTDsestablish the ID type in the Infoset whereas W3C XML Schemaproduces a PSVI but does not modify the original Infoset. Thisleaves open the possibility that a processor might only look in theInfoset and consequently would fail to recognize schema-assignedIDs.
See the TAG issuexmlIDSemantics-32 for additional background informationand [XML-ID] for a solutionunder development.
RFC 3023 defines the Internet mediatypes "application/xml" and "text/xml", and describes a conventionwhereby XML-based data formats use Internet media types with a"+xml" suffix, for example "image/svg+xml".
There are two problems associatedwith the “text” media types: First, for data identified as"text/*", Web intermediaries are allowed to "transcode", i.e.,convert one character encoding to another. Transcoding may make theself-description false or may cause the document to be notwell-formed.
Goodpractice:XMLand "text/*"
In general, arepresentation provider SHOULD NOT assign Internet media typesbeginning with "text/" to XML representations.
Second, representations whoseInternet media types begin with "text/" are required, unless thecharset parameter is specified, to be considered to beencoded in US-ASCII. Since the syntax of XML is designed to makedocuments self-describing, it is good practice to omit thecharset parameter, and since XML is very often notencoded in US-ASCII, the use of "text/" Internet media typeseffectively precludes this good practice.
Goodpractice:XML andcharacter encodings
In general, arepresentation provider SHOULD NOT specify the character encodingfor XML data in protocol headers since the data isself-describing.
The section onmedia types and fragmentidentifier semantics (§3.2.1) discusses the interpretation offragment identifiers. Designers of an XML-based data formatspecification should define the semantics of fragment identifiersin that format. The XPointer Framework [XPTRFR] provides an interoperable starting point.
When the media type assigned torepresentation data is "application/xml", there are no semanticsdefined for fragment identifiers, and authors should not make useof fragment identifiers in such data. The same is true if theassigned media type has the suffix "+xml" (defined in "XML MediaTypes" [RFC3023]), and the dataformat specification does not specify fragment identifiersemantics. In short, just knowing that content is XML does notprovide information about fragment identifier semantics.
Many people assume that thefragment identifier#abc, when referring to XML data,identifies the element in the document with the ID "abc". However,there is no normative support for this assumption. A revision ofRFC 3023 is expected to address this.
See TAG issuefragmentInXML-28.
4.6.Future Directions for Data Formats
Data formats enable the creation ofnew applications to make use of the information spaceinfrastructure. The Semantic Web is one such application, built ontop of RDF [RDFXML]. Thisdocument does not discuss the Semantic Web in detail; the TAGexpects that future volumes of this document will. See the relatedTAG issuehttpRange-14.
A number of general architectureprinciples apply to all three bases of Web architecture.
Identification, interaction, andrepresentation are orthogonal concepts, meaning that technologiesused for identification, interaction, and representation may evolveindependently. For instance:
- Resources are identified with URIs. URIs can be publishedwithout building any representations of the resource or determiningwhether any representations are available.
- A generic URI syntax allows agents to function in many caseswithout knowing specifics of URI schemes.
- In many cases one may change the representation of a resourcewithout disrupting references to the resource (for example, byusingcontentnegotiation).
When two specifications areorthogonal, one may change one without requiring changes to theother, even if one has dependencies on the other. For example,although the HTTP specification depends on the URI specification,the two may evolve independently. This orthogonality increases theflexibility and robustness of the Web. For example, one may referby URI to an image without knowing anything about the format chosento represent the image. This has facilitated the introduction ofimage formats such as PNG and SVG without disrupting existingreferences to image resources.
Principle:Orthogonality
Orthogonalabstractions benefit from orthogonal specifications.
Experience demonstrates thatproblems arise where orthogonal concepts occur in a singlespecification. Consider, for example, the HTML specification whichincludes the orthogonal x-www-form-urlencoded specification.Software developers (for example, of [CGI] applications) might have an easier time finding thespecification if it were published separately and then cited fromthe HTTP, URI, and HTML specifications.
Problems also arise whenspecifications attempt to modify orthogonal abstractions describedelsewhere. Anhistorical version of the HTML specification addeda "Refresh" value to thehttp-equivattribute of themeta element. It was defined to beequivalent to the HTTP header of the same name. The authors of theHTTP specification ultimately decided not to provide this headerand that made the two specifications awkwardly at odds with eachother. The W3C HTML Working Group eventually removed the"Refresh" value.
A specification should clearlyindicate which features overlap with those governed by anotherspecification.
The information in the Web and thetechnologies used to represent that information change over time.Extensibility is the property of a technology that promotesevolution without sacrificing interoperability. Some examples ofsuccessful technologies designed to allow change while minimizingdisruption include:
- the fact that URI schemes are orthogonally specified;
- the use of an open set of Internet media types in mail and HTTPto specify document interpretation;
- the separation of the generic XML grammar and the open set ofXML namespaces for element and attribute names;
- extensibility models in Cascading Style Sheets (CSS), XSLT 1.0,and SOAP;
- user agent plug-ins.
An example of an unsuccessfulextension mechanism is HTTP mandatory extensions [HTTPEXT]. The community has soughtmechanisms to extend HTTP, but apparently the costs of themandatory extension proposal (notably in complexity) outweighed thebenefits and thus hampered adoption.
Below we discuss the property of"extensibility," exhibited by URIs, some data formats, and someprotocols (through the incorporation of new messages).
Subset language: one language is asubset (or "profile") of a second language if any document in thefirst language is also a valid document in the second language andhas the same interpretation in the second language.
Extended language: If onelanguage is a subset of another, the latter superset is called anextended language; the difference between the languages is calledthe extension. Clearly, extending a language is better forinteroperability than creating an incompatible language.
Ideally, many instances of asuperset language can be safely and usefully processed as thoughthey were in the subset language. Languages that can evolve thisway, allowing applications to provide new information whennecessary while still interoperating with applications that onlyunderstand a subset of the current language, are said to be"extensible." Language designers can facilitate extensibility bydefining the default behavior of unknown extensions—for example,that they be ignored (in some defined way) or should be considerederrors.
For example, from early on in theWeb, HTML agents followed the convention of ignoring unknown tags.This choice left room for innovation (i.e., non-standard elements)and encouraged the deployment of HTML. However, interoperabilityproblems arose as well. In this type of environment, there is aninevitable tension between interoperability in the short term andthe desire for extensibility. Experience shows that designs thatstrike the right balance between allowing change and preservinginteroperability are more likely to thrive and are less likely todisrupt the Web community.Orthogonal specifications (§5.1) help reduce the risk ofdisruption.
For further discussion, see thesection onversioning andextensibility (§4.2). See also TAG issuexmlProfiles-29 andHTMLDialects.
Errors occur in networkedinformation systems. An error condition can be well-characterized(e.g., well-formedness errors in XML or 4xx client errors in HTTP)or arise unpredictably.Error correction means thatan agent repairs a condition so that within the system, it is asthough the error never occurred. One example of error correctioninvolves data retransmission in response to a temporary networkfailure.Error recovery means that anagent does not repair an error condition but continues processingby addressing the fact that the error has occurred.
Agents frequentlycorrecterrors without user awareness, sparing users the details of complexnetwork communications. On the other hand, it is important thatagentsrecover from error in a way that is evident tousers, since the agents are acting on their behalf.
Principle:Error recovery
Agents thatrecover from error by making a choice without the user's consentare not acting on the user's behalf.
An agent is not required tointerrupt the user (e.g., by popping up a confirmation box) toobtain consent. The user may indicate consent through pre-selectedconfiguration options, modes, or selectable user interface toggles,with appropriate reporting to the user when the agent detects anerror. Agent developers should not ignore usability issues whendesigning error recovery behavior.
To promote interoperability,specification designers should identify predictable errorconditions. Experience has led to the following observations abouterror-handling approaches.
- Protocol designers should provide enough information about anerror condition so that an agent can address the error condition.For instance, an HTTP 404 status code (not found) is useful becauseit allows user agents to present relevant information to users,enabling them to contact the representation provider in case ofproblems.
- Experience with the cost of building a user agent to handle thediverse forms of ill-formed HTML content convinced the designers ofthe XML specification to require that agents fail upon encounteringill-formed content. Because users are unlikely to tolerate suchfailures, this design choice has pressured all parties intorespecting XML's constraints, to the benefit of all.
- An agent that encounters unrecognized content may handle it ina number of ways, including by considering it an error; see alsothe section onextensibility and versioning (§4.2).
- Error behavior that is appropriate for a person may not beappropriate for software. People are capable of exercisingjudgement in ways that software applications generally cannot. Aninformal error response may suffice for a person but not for aprocessor.
See the TAG issuecontentTypeOverride-24, which concerns the sourceof authoritative metadata.
This document was authored by theW3C Technical Architecture Group which included the followingparticipants: Tim Berners-Lee (co-Chair, W3C), Tim Bray (AntarcticaSystems), Dan Connolly (W3C), Paul Cotton (Microsoft Corporation),Roy Fielding (Day Software), Mario Jeckle (Daimler Chrysler), ChrisLilley (W3C), Noah Mendelsohn (IBM), David Orchard (BEA Systems),Norman Walsh (Sun Microsystems), and Stuart Williams (co-Chair,Hewlett-Packard).
The TAG appreciates the manycontributions on the TAG's public mailing list, www-tag@w3.org(archive), which have helped to improve thisdocument.
In addition, contributions by DavidBooth, Erik Bruchez, Kendall Clark, Karl Dubost, Bob DuCharme,Martin Duerst, Olivier Fehr, Al Gilman, Tim Goodwin, Elliotte RustyHarold, Tony Hammond, Sandro Hawke, Ryan Hayes, DominiqueHazaël-Massieux, Masayasu Ishikawa, David M. Karr, Graham Klyne,Jacek Kopecky, Ken Laskey, Susan Lesch, Håkon Wium Lie, FrankManola, Mark Nottingham, Bijan Parsia, Peter F. Patel-Schneider,David Pawson, Michael Sperberg-McQueen, Patrick Stickler, andYuxiao Zhao are gratefully acknowledged.
