You are on page 1of 52

09/10/12

Architecture of the World Wide Web, Volume One

ArchitectureoftheWorldWideWeb,Volume One
W3CRecommendation15December2004
Thisversion: http://www.w3.org/TR/2004/RECwebarch20041215/ Latestversion: http://www.w3.org/TR/webarch/ Previousversion: http://www.w3.org/TR/2004/PRwebarch20041105/ Editors: IanJacobs,W3C NormanWalsh,SunMicrosystems,Inc. Authors: Seeacknowledgments(8). Pleaserefertotheerrataforthisdocument,whichmayincludesomenormative corrections. Seealsotranslations.
Copyright20022004W3C(MIT,ERCIM,Keio),AllRightsReserved.W3Cliability,trademark, documentuseandsoftwarelicensingrulesapply.Yourinteractionswiththissiteareinaccordance withourpublicandMemberprivacystatements.

Abstract
TheWorldWideWebusesrelativelysimpletechnologieswithsufficientscalability, efficiencyandutilitythattheyhaveresultedinaremarkableinformationspaceof interrelatedresources,growingacrosslanguages,cultures,andmedia.Inaneffort topreservethesepropertiesoftheinformationspaceasthetechnologiesevolve, thisarchitecturedocumentdiscussesthecoredesigncomponentsoftheWeb. Theyareidentificationofresources,representationofresourcestate,andthe protocolsthatsupporttheinteractionbetweenagentsandresourcesinthespace. Werelatecoredesigncomponents,constraints,andgoodpracticestothe principlesandpropertiestheysupport.

Statusofthisdocument
Thissectiondescribesthestatusofthisdocumentatthetimeofitspublication.
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits 1/52

09/10/12

Architecture of the World Wide Web, Volume One

Otherdocumentsmaysupersedethisdocument.AlistofcurrentW3Cpublications andthelatestrevisionofthistechnicalreportcanbefoundintheW3Ctechnical reportsindexathttp://www.w3.org/TR/. Thisisthe15December2004RecommendationofArchitectureoftheWorldWide Web,VolumeOne.ThisdocumenthasbeenreviewedbyW3CMembers,by softwaredevelopers,andbyotherW3Cgroupsandinterestedparties,andis endorsedbytheDirectorasaW3CRecommendation.Itisastabledocumentand maybeusedasreferencematerialorcitedfromanotherdocument.W3C'srolein makingtheRecommendationistodrawattentiontothespecificationandto promoteitswidespreaddeployment.Thisenhancesthefunctionalityand interoperabilityoftheWeb. ThisdocumentwasdevelopedbyW3C'sTechnicalArchitectureGroup(TAG), which,bychartermaintainsalistofarchitecturalissues.Thescopeofthis documentisausefulsubsetofthoseissuesitisnotintendedtoaddressallof them.TheTAGintendstoaddresstheremaining(andfuture)issuesnowthat VolumeOneispublishedasaW3CRecommendation.Acompletehistoryof changessothisdocumentisavailable.Pleasesendcommentsonthisdocumentto publicwebarchcomments@w3.org(publicarchiveofpublicwebarchcomments). TAGtechnicaldiscussiontakesplaceonwwwtag@w3.org(publicarchiveof wwwtag). ThisdocumentwasproducedundertheW3CIPRpolicyoftheJuly2001Process Document.TheTAGmaintainsapubliclistofpatentdisclosuresrelevanttothis documentthatpagealsoincludesinstructionsfordisclosingapatent.Anindividual whohasactualknowledgeofapatentwhichtheindividualbelievescontains EssentialClaim(s)withrespecttothisspecificationshoulddisclosetheinformation inaccordancewithsection6oftheW3CPatentPolicy.

TableofContents
1.Introduction 1.1.AboutthisDocument 1.1.1.AudienceofthisDocument 1.1.2.ScopeofthisDocument 1.1.3.Principles,Constraints,andGoodPracticeNotes 2.Identification 2.1.BenefitsofURIs 2.2.URI/ResourceRelationships 2.2.1.URIcollision 2.2.2.URIallocation 2.2.3.IndirectIdentification 2.3.URIComparisons 2.3.1.URIaliases 2.3.2.Representationreuse 2.4.URISchemes 2.4.1.URISchemeRegistration 2.5.URIOpacity 2.6.FragmentIdentifiers 2.7.FutureDirectionsforIdentifiers 2.7.1.Internationalizedidentifiers 2.7.2.AssertionthattwoURIsidentifythesameresource 3.Interaction
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits 2/52

09/10/12

Architecture of the World Wide Web, Volume One

3.1.UsingaURItoAccessaResource 3.1.1.Detailsofretrievingarepresentation 3.2.RepresentationTypesandInternetMediaTypes 3.2.1.Representationtypesandfragmentidentifiersemantics 3.2.2.Fragmentidentifiersandcontentnegotiation 3.3.InconsistenciesbetweenRepresentationDataandMetadata 3.4.SafeInteractions 3.4.1.Unsafeinteractionsandaccountability 3.5.RepresentationManagement 3.5.1.URIpersistence 3.5.2.Linkingandaccesscontrol 3.5.3.SupportingNavigation 3.6.FutureDirectionsforInteraction 4.DataFormats 4.1.BinaryandTextualDataFormats 4.2.VersioningandExtensibility 4.2.1.Versioning 4.2.2.VersioningandXMLnamespacepolicy 4.2.3.Extensibility 4.2.4.Compositionofdataformats 4.3.SeparationofContent,Presentation,andInteraction 4.4.Hypertext 4.4.1.URIreferences 4.5.XMLBasedDataFormats 4.5.1.WhentouseanXMLbasedformat 4.5.2.LinksinXML 4.5.3.XMLnamespaces 4.5.4.Namespacedocuments 4.5.5.QNamesinXML 4.5.6.XMLIDsemantics 4.5.7.MediatypesforXML 4.5.8.FragmentidentifiersinXML 4.6.FutureDirectionsforDataFormats 5.GeneralArchitecturePrinciples 5.1.OrthogonalSpecifications 5.2.Extensibility 5.3.ErrorHandling 5.4.ProtocolbasedInteroperability 6.Glossary 7.References 7.1.ArchitecturalSpecifications 8.Acknowledgments

ListofPrinciples,Constraints,andGoodPracticeNotes
Thefollowingprinciples,constraints,andgoodpracticenotesarediscussedinthis documentandlistedhereforconvenience.Thereisalsoafreestandingsummary. Identification GlobalIdentifiers(principle,2) IdentifywithURIs(practice,2.1) URIsIdentifyaSingleResource(constraint,2.2) AvoidingURIaliases(practice,2.3.1)
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits 3/52

09/10/12

Architecture of the World Wide Web, Volume One

ConsistentURIusage(practice,2.3.1) ReuseURIschemes(practice,2.4) URIopacity(practice,2.5) Interaction Reuserepresentationformats(practice,3.2) Datametadatainconsistency(constraint,3.3) Metadataassociation(practice,3.3) Saferetrieval(principle,3.4) Availablerepresentation(practice,3.5) Referencedoesnotimplydereference(principle,3.5) Consistentrepresentation(practice,3.5.1) DataFormats Versioninformation(practice,4.2.1) Namespacepolicy(practice,4.2.2) Extensibilitymechanisms(practice,4.2.3) Extensibilityconformance(practice,4.2.3) Unknownextensions(practice,4.2.3) Separationofcontent,presentation,interaction(practice,4.3) Linkidentification(practice,4.4) Weblinking(practice,4.4) GenericURIs(practice,4.4) Hypertextlinks(practice,4.4) Namespaceadoption(practice,4.5.3) Namespacedocuments(practice,4.5.4) QNamesIndistinguishablefromURIs(constraint,4.5.5) QNameMapping(practice,4.5.5) XMLand"text/*"(practice,4.5.7) XMLandcharacterencodings(practice,4.5.7) GeneralArchitecturePrinciples Orthogonality(principle,5.1) Errorrecovery(principle,5.3)

1.Introduction
TheWorldWideWeb(WWW,orsimplyWeb)isaninformationspaceinwhichthe itemsofinterest,referredtoasresources,areidentifiedbyglobalidentifierscalled UniformResourceIdentifiers(URI). Examplessuchasthefollowingtravelscenarioareusedthroughoutthisdocument toillustratetypicalbehaviorofWebagentspeopleorsoftwareactingonthis informationspace.Auseragentactsonbehalfofauser.Softwareagentsinclude servers,proxies,spiders,browsers,andmultimediaplayers.

Story

www.w3.org/TR/2004/RECwebarch20041215/#uribenefits

4/52

09/10/12

Architecture of the World Wide Web, Volume One

WhileplanningatriptoMexico,NadiareadsOaxacaweather information:'http://weather.example.com/oaxaca'inaglossytravel magazine.NadiahasenoughexperiencewiththeWebtorecognizethat "http://weather.example.com/oaxaca"isaURIandthatsheislikelytobe abletoretrieveassociatedinformationwithherWebbrowser.When NadiaenterstheURIintoherbrowser: 1. ThebrowserrecognizesthatwhatNadiatypedisaURI. 2. Thebrowserperformsaninformationretrievalactioninaccordance withitsconfiguredbehaviorforresourcesidentifiedviathe"http" URIscheme. 3. Theauthorityresponsiblefor"weather.example.com"provides informationinaresponsetotheretrievalrequest. 4. Thebrowserinterpretstheresponse,identifiedasXHTMLbythe server,andperformsadditionalretrievalactionsforinlinegraphics andothercontentasnecessary. 5. Thebrowserdisplaystheretrievedinformation,whichincludes hypertextlinkstootherinformation.Nadiacanfollowthese hypertextlinkstoretrieveadditionalinformation. ThisscenarioillustratesthethreearchitecturalbasesoftheWebthatarediscussed inthisdocument: 1. Identification(2).URIsareusedtoidentifyresources.Inthistravelscenario, theresourceisaperiodicallyupdatedreportontheweatherinOaxaca,and theURIishttp://weather.example.com/oaxaca. 2. Interaction(3).Webagentscommunicateusingstandardizedprotocolsthat enableinteractionthroughtheexchangeofmessageswhichadheretoa definedsyntaxandsemantics.ByenteringaURIintoaretrievaldialogor selectingahypertextlink,Nadiatellsherbrowsertoperformaretrievalaction fortheresourceidentifiedbytheURI.Inthisexample,thebrowsersendsan HTTPGETrequest(partoftheHTTPprotocol)totheserverat "weather.example.com",viaTCP/IPport80,andtheserversendsbacka messagecontainingwhatitdeterminestobearepresentationoftheresource asofthetimethatrepresentationwasgenerated.Notethatthisexampleis specifictohypertextbrowsingofinformationotherkindsofinteractionare possible,bothwithinbrowsersandthroughtheuseofothertypesofWeb agentourexampleisintendedtoillustrateonecommoninteraction,not definetherangeofpossibleinteractionsorlimitthewaysinwhichagents mightusetheWeb. 3. Formats(4).Mostprotocolsusedforrepresentationretrievaland/or submissionmakeuseofasequenceofoneormoremessages,whichtaken togethercontainapayloadofrepresentationdataandmetadata,totransfer therepresentationbetweenagents.Thechoiceofinteractionprotocolplaces limitsontheformatsofrepresentationdataandmetadatathatcanbe transmitted.HTTP,forexample,typicallytransmitsasingleoctetstreamplus metadata,andusesthe"ContentType"and"ContentEncoding"header fieldstofurtheridentifytheformatoftherepresentation.Inthisscenario,the representationtransferredisinXHTML,asidentifiedbythe"Contenttype" HTTPheaderfieldcontainingtheregisteredInternetmediatypename, "application/xhtml+xml".ThatInternetmediatypenameindicatesthatthe representationdatacanbeprocessedaccordingtotheXHTMLspecification.
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits 5/52

09/10/12

Architecture of the World Wide Web, Volume One

Nadia'sbrowserisconfiguredandprogrammedtointerpretthereceiptofan "application/xhtml+xml"typedrepresentationasaninstructiontorenderthe contentofthatrepresentationaccordingtotheXHTMLrenderingmodel, includinganysubsidiaryinteractions(suchasrequestsforexternalstyle sheetsorinlineimages)calledforbytherepresentation.Inthescenario,the XHTMLrepresentationdatareceivedfromtheinitialrequestinstructsNadia's browsertoalsoretrieveandrenderinlinetheweathermaps,eachidentified byaURIandthuscausinganadditionalretrievalaction,resultingin additionalrepresentationsthatareprocessedbythebrowseraccordingto theirowndataformats(e.g.,"application/svg+xml"indicatestheSVGdata format),andthisprocesscontinuesuntilallofthedataformatshavebeen rendered.Theresultofallofthisprocessing,oncethebrowserhasreached anapplicationsteadystatethatcompletesNadia'sinitialrequestedaction,is commonlyreferredtoasa"Webpage". Thefollowingillustrationshowstherelationshipbetweenidentifier,resource,and representation.

Intheremainderofthisdocument,wehighlightimportantarchitecturalpoints regardingWebidentifiers,protocols,andformats.Wealsodiscusssomeimportant generalarchitecturalprinciples(5)andhowtheyapplytotheWeb.


www.w3.org/TR/2004/RECwebarch20041215/#uribenefits 6/52

09/10/12

Architecture of the World Wide Web, Volume One

1.1.AboutthisDocument
ThisdocumentdescribesthepropertieswedesireoftheWebandthedesign choicesthathavebeenmadetoachievethem.Itpromotesthereuseofexisting standardswhensuitable,andgivesguidanceonhowtoinnovateinamanner consistentwithWebarchitecture. ThetermsMUST,MUSTNOT,SHOULD,SHOULDNOT,andMAYareusedinthe principles,constraints,andgoodpracticenotesinaccordancewithRFC2119 [RFC2119]. Thisdocumentdoesnotincludeconformanceprovisionsforthesereasons: Conformingsoftwareisexpectedtobesodiversethatitwouldnotbeuseful tobeabletorefertotheclassofconformingsoftwareagents. Someofthegoodpracticenotesconcernpeoplespecificationsgenerally defineconformanceforsoftware,notpeople. Wedonotbelievethattheadditionofaconformancesectionislikelyto increasetheutilityofthedocument. 1.1.1.AudienceofthisDocument ThisdocumentisintendedtoinformdiscussionsaboutissuesofWebarchitecture. Theintendedaudienceforthisdocumentincludes: 1. ParticipantsinW3CActivities 2. Othergroupsandindividualsdesigningtechnologiestobeintegratedintothe Web 3. ImplementersofW3Cspecifications 4. Webcontentauthorsandpublishers Note:Thisdocumentdoesnotdistinguishinanyformalwaytheterms"language" and"format."Contextdetermineswhichtermisused.Thephrase"specification designer"encompasseslanguage,format,andprotocoldesigners. 1.1.2.ScopeofthisDocument ThisdocumentpresentsthegeneralarchitectureoftheWeb.Othergroupsinside andoutsideW3CalsoaddressspecializedaspectsofWebarchitecture,including accessibility,qualityassurance,internationalization,deviceindependence,and WebServices.ThesectiononArchitecturalSpecifications(7.1)includes referencestotheserelatedspecifications. Thisdocumentstrivesforabalancebetweenbrevityandprecisionwhileincluding illustrativeexamples.TAGfindingsareinformationaldocumentsthatcomplement thecurrentdocumentbyprovidingmoredetailaboutselectedtopics.This documentincludessomeexcerptsfromthefindings.Sincethefindingsevolve independently,thisdocumentincludesreferencestoapprovedTAGfindings.For otherTAGissuescoveredbythisdocumentbutwithoutanapprovedfinding, referencesaretoentriesintheTAGissueslist. Manyoftheexamplesinthisdocumentthatinvolvehumanactivitysupposethe familiarWebinteractionmodel(illustratedatthebeginningoftheIntroduction) whereapersonfollowsalinkviaauseragent,theuseragentretrievesand www.w3.org/TR/2004/RECwebarch20041215/#uribenefits presentsdata,theuserfollowsanotherlink,etc.Thisdocumentdoesnotdiscussin

7/52

09/10/12

Architecture of the World Wide Web, Volume One

presentsdata,theuserfollowsanotherlink,etc.Thisdocumentdoesnotdiscussin anydetailotherinteractionmodelssuchasvoicebrowsing(see,forexample, [VOICEXML2]).Thechoiceofinteractionmodelmayhaveanimpactonexpected agentbehavior.Forinstance,whenagraphicaluseragentrunningonalaptop computerorhandhelddeviceencountersanerror,theuseragentcanreporterrors directlytotheuserthroughvisualandaudiocues,andpresenttheuserwith optionsforresolvingtheerrors.Ontheotherhand,whensomeoneisbrowsingthe Webthroughvoiceinputandaudioonlyoutput,stoppingthedialogtowaitforuser inputmayreduceusabilitysinceitissoeasyto"loseone'splace"whenbrowsing withonlyaudiooutput.Thisdocumentdoesnotdiscusshowtheprinciples, constraints,andgoodpracticesidentifiedhereapplyinallinteractioncontexts. 1.1.3.Principles,Constraints,andGoodPracticeNotes Theimportantpointsofthisdocumentarecategorizedasfollows: Principle Anarchitecturalprincipleisafundamentalrulethatappliestoalargenumber ofsituationsandvariables.Architecturalprinciplesinclude"separationof concerns","genericinterface","selfdescriptivesyntax,""visiblesemantics," "networkeffect"(Metcalfe'sLaw),andAmdahl'sLaw:"Thespeedofasystem islimitedbyitsslowestcomponent." Constraint InthedesignoftheWeb,somechoices,likethenamesofthep andl i elementsinHTML,thechoiceofthecolon(:)characterinURIs,orgrouping bitsintoeightbitunits(octets),aresomewhatarbitraryifp a r a g r a p h hadbeen choseninsteadofp orasterisk(*)insteadofcolon,thelargescaleresult would,mostlikely,havebeenthesame.Thisdocumentfocusesonmore fundamentaldesignchoices:designchoicesthatleadtoconstraints,i.e., restrictionsinbehaviororinteractionwithinthesystem.Constraintsmaybe imposedfortechnical,policy,orotherreasonstoachievedesirableproperties inthesystem,suchasaccessibility,globalscope,relativeeaseofevolution, efficiency,anddynamicextensibility. Goodpractice Goodpracticebysoftwaredevelopers,contentauthors,sitemanagers, users,andspecificationdesignersincreasesthevalueoftheWeb.

2.Identification
Inordertocommunicateinternally,acommunityagrees(toareasonableextent)on asetoftermsandtheirmeanings.OnegoaloftheWeb,sinceitsinception,has beentobuildaglobalcommunityinwhichanypartycanshareinformationwithany otherparty.Toachievethisgoal,theWebmakesuseofasingleglobal identificationsystem:theURI.URIsareacornerstoneofWebarchitecture, providingidentificationthatiscommonacrosstheWeb.TheglobalscopeofURIs promoteslargescale"networkeffects":thevalueofanidentifierincreasesthemore itisusedconsistently(forexample,themoreitisusedinhypertextlinks(4.4)).

Principle:GlobalIdentifiers Globalnamingleadstoglobalnetworkeffects.
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits 8/52

09/10/12

Architecture of the World Wide Web, Volume One

ThisprincipledatesbackatleastasfarasDouglasEngelbart'sseminalworkon openhypertextsystemsseesectionEveryObjectAddressablein[Eng90].

2.1.BenefitsofURIs
Thechoiceofsyntaxforglobalidentifiersissomewhatarbitraryitistheirglobal scopethatisimportant.TheUniformResourceIdentifier,[URI],hasbeen successfullydeployedsincethecreationoftheWeb.Therearesubstantialbenefits toparticipatingintheexistingnetworkofURIs,includinglinking,bookmarking, caching,andindexingbysearchengines,andtherearesubstantialcoststo creatinganewidentificationsystemthathasthesamepropertiesasURIs.

Goodpractice:IdentifywithURIs TobenefitfromandincreasethevalueoftheWorldWideWeb,agents shouldprovideURIsasidentifiersforresources. AresourceshouldhaveanassociatedURIifanotherpartymightreasonablywant tocreateahypertextlinktoit,makeorrefuteassertionsaboutit,retrieveorcachea representationofit,includeallorpartofitbyreferenceintoanotherrepresentation, annotateit,orperformotheroperationsonit.Softwaredevelopersshouldexpect thatsharingURIsacrossapplicationswillbeuseful,evenifthatutilityisnotinitially evident.TheTAGfinding"URIs,Addressability,andtheuseofHTTPGETand POST"discussesadditionalbenefitsandconsiderationsofURIaddressability. Note:SomeURIschemes(suchasthe"ftp"URIschemespecification)usethe term"designate"wherethisdocumentuses"identify."

2.2.URI/ResourceRelationships
BydesignaURIidentifiesoneresource.Wedonotlimitthescopeofwhatmightbe aresource.Theterm"resource"isusedinageneralsenseforwhatevermightbe identifiedbyaURI.ItisconventionalonthehypertextWebtodescribeWebpages, images,productcatalogs,etc.asresources.Thedistinguishingcharacteristicof theseresourcesisthatalloftheiressentialcharacteristicscanbeconveyedina message.Weidentifythissetasinformationresources. Thisdocumentisanexampleofaninformationresource.Itconsistsofwordsand punctuationsymbolsandgraphicsandotherartifactsthatcanbeencoded,with varyingdegreesoffidelity,intoasequenceofbits.Thereisnothingaboutthe essentialinformationcontentofthisdocumentthatcannotinprinciplebetransfered inamessage.Inthecaseofthisdocument,themessagepayloadisthe representationofthisdocument. However,ouruseofthetermresourceisintentionallymorebroad.Otherthings, suchascarsanddogs(and,ifyou'veprintedthisdocumentonphysicalsheetsof paper,theartifactthatyouareholdinginyourhand),areresourcestoo.Theyare notinformationresources,however,becausetheiressenceisnotinformation. Althoughitispossibletodescribeagreatmanythingsaboutacaroradogina sequenceofbits,thesumofthosethingswillinvariablybeanapproximationofthe
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits 9/52

09/10/12

Architecture of the World Wide Web, Volume One

essentialcharacteroftheresource. Wedefinetheterminformationresourcebecauseweobservethatitisusefulin discussionsofWebtechnologyandmaybeusefulinconstructingspecificationsfor facilitiesbuiltforuseontheWeb.

Constraint:URIsIdentifyaSingleResource AssigndistinctURIstodistinctresources. SincethescopeofaURIisglobal,theresourceidentifiedbyaURIdoesnot dependonthecontextinwhichtheURIappears(seealsothesectionabout indirectidentification(2.2.3)). [URI]isanagreementabouthowtheInternetcommunityallocatesnamesand associatesthemwiththeresourcestheyidentify.URIsaredividedintoschemes (2.4)thatdefine,viatheirschemespecification,themechanismbywhichscheme specificidentifiersareassociatedwithresources.Forexample,the"http"URI scheme([RFC2616])usesDNSandTCPbasedHTTPserversforthepurposeof identifierallocationandresolution.Asaresult,identifierssuchas "http://example.com/somepath#someFrag"oftentakeonmeaningthroughthe communityexperienceofperforminganHTTPGETrequestontheidentifierand,if givenasuccessfulresponse,interpretingtheresponseasarepresentationofthe identifiedresource.(SeealsoFragmentIdentifiers(2.6).)Ofcourse,aretrieval actionlikeGETisnottheonlywaytoobtaininformationaboutaresource.One mightalsopublishadocumentthatpurportstodefinethemeaningofaparticular URI.Theseothersourcesofinformationmaysuggestmeaningsforsuchidentifiers, butit'salocalpolicydecisionwhetherthosesuggestionsshouldbeheeded. Justasonemightwishtorefertoapersonbydifferentnames(byfullname,first nameonly,sportsnickname,romanticnickname,andsoforth),Webarchitecture allowstheassociationofmorethanoneURIwitharesource.URIsthatidentifythe sameresourcearecalledURIaliases.ThesectiononURIaliases(2.3.1) discussessomeofthepotentialcostsofcreatingmultipleURIsforthesame resource. Severalsectionsofthisdocumentaddressquestionsabouttherelationship betweenURIsandresources,including: HowmuchcanItellaboutaresourcebyinspectionofaURIthatidentifiesit? SeethesectionsonURIschemes(2.4)andURIopacity(2.5). WhodetermineswhatresourceaURIidentifies?SeethesectiononURI allocation(2.2.2). CantheresourceidentifiedbyaURIchangeovertime?Seethesectionson URIpersistence(3.5.1)andrepresentationmanagement(3.5). SincemorethanoneURIcanidentifythesameresource,howdoIknow whichURIsidentifythesameresource?SeethesectionsonURIcomparison (2.3)andassertionsthattwoURIsidentifythesameresource(2.7.2). 2.2.1.URIcollision

www.w3.org/TR/2004/RECwebarch20041215/#uribenefits

10/52

09/10/12

Architecture of the World Wide Web, Volume One

Bydesign,aURIidentifiesoneresource.UsingthesameURItodirectlyidentify differentresourcesproducesaURIcollision.Collisionoftenimposesacostin communicationduetotheeffortrequiredtoresolveambiguities. Suppose,forexample,thatoneorganizationmakesuseofaURItorefertothe movieTheSting,andanotherorganizationusesthesameURItorefertoa discussionforumaboutTheSting.Toathirdparty,awareofbothorganizations, thiscollisioncreatesconfusionaboutwhattheURIidentifies,underminingthe valueoftheURI.Ifonewantedtotalkaboutthecreationdateoftheresource identifiedbytheURI,forinstance,itwouldnotbeclearwhetherthismeant"when themoviewascreated"or"whenthediscussionforumaboutthemoviewas created." SocialandtechnicalsolutionshavebeendevisedtohelpavoidURIcollision. However,thesuccessorfailureofthesedifferentapproachesdependsonthe extenttowhichthereisconsensusintheInternetcommunityonabidingbythe definingspecifications. ThesectiononURIallocation(2.2.2)examinesapproachesforestablishingthe authoritativesourceofinformationaboutwhatresourceaURIidentifies. URIsaresometimesusedforindirectidentification(2.2.3).Thisdoesnot necessarilyleadtocollisions. 2.2.2.URIallocation URIallocationistheprocessofassociatingaURIwitharesource.Allocationcan beperformedbothbyresourceownersandbyotherparties.Itisimportanttoavoid URIcollision(2.2.1). 2.2.2.1.URIownership URIownershipisarelationbetweenaURIandasocialentity,suchasaperson, organization,orspecification.URIownershipgivestherelevantsocialentitycertain rights,including: 1. topassonownershipofsomeorallownedURIstoanotherowner delegationand 2. toassociatearesourcewithanownedURIURIallocation. Bysocialconvention,URIownershipisdelegatedfromtheIANAURIscheme registry[IANASchemes],itselfasocialentity,toIANAregisteredURIscheme specifications.SomeURIschemespecificationsfurtherdelegateownershipto subordinateregistriesortoothernominatedowners,whomayfurtherdelegate ownership.Inthecaseofaspecification,ownershipultimatelylieswiththe communitythatmaintainsthespecification. Theapproachtakenforthe"http"URIscheme,forexample,followsthepattern wherebytheInternetcommunitydelegatesauthority,viatheIANAURIscheme registryandtheDNS,overasetofURIswithacommonprefixtooneparticular owner.OneconsequenceofthisapproachistheWeb'sheavyrelianceonthe centralDNSregistry.AdifferentapproachistakenbytheURNSyntaxscheme [RFC2141]whichdelegatesownershipofportionsofURNspacetoURN NamespacespecificationswhichthemselvesareregisteredinanIANAmaintained
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits 11/52

09/10/12

Architecture of the World Wide Web, Volume One

registryofURNNamespaceIdentifiers. URIownersareresponsibleforavoidingtheassignmentofequivalentURIsto multipleresources.Thus,ifaURIschemespecificationdoesprovideforthe delegationofindividualororganizedsetsofURIs,itshouldtakepainstoensure thatownershipultimatelyresidesinthehandsofasinglesocialentity.Allowing multipleownersincreasesthelikelihoodofURIcollisions. URIownersmayorganizeordeployinfrastruturetoensurethatrepresentationsof associatedresourcesareavailableand,whereappropriate,interactionwiththe resourceispossiblethroughtheexchangeofrepresentations.Therearesocial expectationsforresponsiblerepresentationmanagement(3.5)byURIowners. AdditionalsocialimplicationsofURIownershiparenotdiscussedhere. SeeTAGissuesiteData36,whichconcernstheexpropriationofnamingauthority. 2.2.2.2.Otherallocationschemes Someschemesusetechniquesotherthandelegatedownershiptoavoidcollision. Forexample,thespecificationforthedataURL(sic)scheme[RFC2397]specifies thattheresourceidentifiedbyadataschemeURIhasonlyonepossible representation.TherepresentationdatamakesuptheURIthatidentifiesthat resource.Thus,thespecificationitselfdetermineshowdataURIsareallocatedno delegationispossible. Otherschemes(suchas"news:comp.text.xml")relyonasocialprocess. 2.2.3.IndirectIdentification TosaythattheURI"mailto:nadia@example.com"identifiesbothanInternet mailboxandNadia,theperson,introducesaURIcollision.However,wecanuse theURItoindirectlyidentifyNadia.Identifiersarecommonlyusedinthisway. Listeningtoanewsbroadcast,onemighthearareportonBritainthatbegins, "Today,10DowningStreetannouncedaseriesofneweconomicmeasures." Generally,"10DowningStreet"identifiestheofficialresidenceofBritain'sPrime Minister.Inthiscontext,thenewsreporterisusingit(asEnglishrhetoricallows)to indirectlyidentifytheBritishgovernment.Similarly,URIsidentifyresources,but theycanalsobeusedinmanyconstructstoindirectlyidentifyotherresources. GloballyadoptedassignmentpoliciesmakesomeURIsappealingasgeneral purposeidentifiers.Localpolicyestablisheswhattheyindirectlyidentify. Supposethatn a d i a @ e x a m p l e . c o m isNadia'semailaddress.Theorganizersofa conferenceNadiaattendsmightuse"mailto:nadia@example.com"torefer indirectlytoher(e.g.,byusingtheURIasadatabasekeyintheirdatabaseof conferenceparticipants).ThisdoesnotintroduceaURIcollision.

2.3.URIComparisons
URIsthatareidentical,characterbycharacter,refertothesameresource.Since WebArchitectureallowstheassociationofmultipleURIswithagivenresource, twoURIsthatarenotcharacterbycharacteridenticalmaystillrefertothesame resource.DifferentURIsdonotnecessarilyrefertodifferentresourcesbutthereis
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits

generallyahighercomputationalcosttodeterminethatdifferentURIsrefertothe

12/52

09/10/12

Architecture of the World Wide Web, Volume One

generallyahighercomputationalcosttodeterminethatdifferentURIsrefertothe sameresource. Toreducetheriskofafalsenegative(i.e.,anincorrectconclusionthattwoURIsdo notrefertothesameresource)orafalsepositive(i.e.,anincorrectconclusionthat twoURIsdorefertothesameresource),somespecificationsdescribeequivalence testsinadditiontocharacterbycharactercomparison.Agentsthatreach conclusionsbasedoncomparisonsthatarenotlicensedbytherelevant specificationstakeresponsibilityforanyproblemsthatresultseethesectionon errorhandling(5.3)formoreinformationaboutresponsiblebehaviorwhen reachingunlicensedconclusions.Section6of[URI]providesmoreinformation aboutcomparingURIsandreducingtheriskoffalsenegativesandpositives. SeealsotheassertionthattwoURIsidentifythesameresource(2.7.2). 2.3.1.URIaliases Althoughtherearebenefits(suchasnamingflexibility)toURIaliases,thereare alsocosts.URIaliasesareharmfulwhentheydividetheWebofrelatedresources. AcorollaryofMetcalfe'sPrinciple(the"networkeffect")isthatthevalueofagiven resourcecanbemeasuredbythenumberandvalueofotherresourcesinits networkneighborhood,thatis,theresourcesthatlinktoit. TheproblemwithaliasesisthatifhalfoftheneighborhoodpointstooneURIfora givenresource,andtheotherhalfpointstoasecond,differentURIforthatsame resource,theneighborhoodisdivided.Notonlyisthealiasedresource undervaluedbecauseofthissplit,theentireneighborhoodofresourceslosesvalue becauseofthemissingsecondorderrelationshipsthatshouldhaveexistedamong thereferringresourcesbyvirtueoftheirreferencestothealiasedresource.

Goodpractice:AvoidingURIaliases AURIownerSHOULDNOTassociatearbitrarilydifferentURIswiththe sameresource. URIconsumersalsohavearoleinensuringURIconsistency.Forinstance,when transcribingaURI,agentsshouldnotgratuitouslypercentencodecharacters.The term"character"referstoURIcharactersasdefinedinsection2of[URI]percent encodingisdiscussedinsection2.1ofthatspecification.

Goodpractice:ConsistentURIusage AnagentthatreceivesaURISHOULDrefertotheassociatedresource usingthesameURI,characterbycharacter. WhenaURIaliasdoesbecomecommoncurrency,theURIownershoulduse protocoltechniquessuchasserversideredirectstorelatethetworesources.The communitybenefitswhentheURIownersupportsredirectionofanaliasedURIto


www.w3.org/TR/2004/RECwebarch20041215/#uribenefits 13/52

09/10/12

Architecture of the World Wide Web, Volume One

thecorresponding"official"URI.Formoreinformationonredirection,seesection 10.3,Redirection,in[RFC2616].Seealso[CHIPS]foradiscussionofsomebest practicesforserveradministrators. 2.3.2.Representationreuse URIaliasingonlyoccurswhenmorethanoneURIisusedtoidentifythesame resource.Thefactthatdifferentresourcessometimeshavethesamerepresentation doesnotmaketheURIsforthoseresourcesaliases.

Story DirkwouldliketoaddalinkfromhisWebsitetotheOaxacaweather site.HeusestheURIhttp://weather.example.com/oaxacaandlabelshis linkreportonweatherinOaxacaon1August2004.Nadiapointsoutto DirkthatheissettingmisleadingexpectationsfortheURIhehasused. TheOaxacaweathersitepolicyisthattheURIinquestionidentifiesa reportonthecurrentweatherinOaxacaonanygivendayandnotthe weatheron1August.Ofcourse,onthefirstofAugustin2004,Dirk'slink willbecorrect,buttherestofthetimehewillbemisleadingreaders. NadiapointsouttoDirkthatthemanagersoftheOaxacaweathersitedo makeavailableadifferentURIpermanentlyassignedtoaresource reportingontheweatheron1August2004. Inthisstory,therearetworesources:areportonthecurrentweatherinOaxaca andareportontheweatherinOaxacaon1August2004.Themanagersofthe OaxacaweathersiteassigntwoURIstothesetwodifferentresources.On 1August2004,therepresentationsfortheseresourcesareidentical.Thatfactthat dereferencingtwodifferentURIsproducesidenticalrepresentationsdoesnotimply thatthetwoURIsarealiases.

2.4.URISchemes
IntheURI"http://weather.example.com/",the"http"thatappearsbeforethecolon (":")namesaURIscheme.EachURIschemehasaspecificationthatexplainsthe schemespecificdetailsofhowschemeidentifiersareallocatedandbecome associatedwitharesource.TheURIsyntaxisthusafederatedandextensible namingsystemwhereineachscheme'sspecificationmayfurtherrestrictthesyntax andsemanticsofidentifierswithinthatscheme. ExamplesofURIsfromvariousschemesinclude: mailto:joe@example.org ftp://example.org/aDirectory/aFile news:comp.infosystems.www tel:+18165551212 ldap://ldap.example.org/c=GB?objectClass?one urn:oasis:names:tc:entity:xmlns:xml:catalog WhileWebarchitectureallowsthedefinitionofnewschemes,introducinganew schemeiscostly.ManyaspectsofURIprocessingareschemedependent,anda
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits 14/52

09/10/12

Architecture of the World Wide Web, Volume One

largeamountofdeployedsoftwarealreadyprocessesURIsofwellknown schemes.IntroducinganewURIschemerequiresthedevelopmentand deploymentnotonlyofclientsoftwaretohandlethescheme,butalsoofancillary agentssuchasgateways,proxies,andcaches.See[RFC2718]forother considerationsandcostsrelatedtoURIschemedesign. Becauseofthesecosts,ifaURIschemeexiststhatmeetstheneedsofan application,designersshoulduseitratherthaninventone.

Goodpractice:ReuseURIschemes AspecificationSHOULDreuseanexistingURIscheme(ratherthan createanewone)whenitprovidesthedesiredpropertiesofidentifiers andtheirrelationtoresources. Considerourtravelscenario:shouldtheagentprovidinginformationaboutthe weatherinOaxacaregisteranewURIscheme"weather"fortheidentificationof resourcesrelatedtotheweather?TheymightthenpublishURIssuchas "weather://travel.example.com/oaxaca".Whenasoftwareagentdereferencessuch aURI,ifwhatreallyhappensisthatHTTPGETisinvokedtoretrievea representationoftheresource,thenan"http"URIwouldhavesufficed. 2.4.1.URISchemeRegistration TheInternetAssignedNumbersAuthority(IANA)maintainsaregistry [IANASchemes]ofmappingsbetweenURIschemenamesandscheme specifications.Forinstance,theIANAregistryindicatesthatthe"http"schemeis definedin[RFC2616].TheprocessforregisteringanewURIschemeisdefinedin [RFC2717]. UnregisteredURIschemesSHOULDNOTbeusedforanumberofreasons: Thereisnogenerallyacceptedwaytolocatetheschemespecification. Someoneelsemaybeusingtheschemeforotherpurposes. Oneshouldnotexpectthatgeneralpurposesoftwarewilldoanythinguseful withURIsofthisschemebeyondURIcomparison. OnemisguidedmotivationforregisteringanewURIschemeistoallowasoftware agenttolaunchaparticularapplicationwhenretrievingarepresentation.Thesame thingcanbeaccomplishedatlowerexpensebydispatchinginsteadonthetypeof therepresentation,therebyallowinguseofexistingtransferprotocolsand implementations. Evenifanagentcannotprocessrepresentationdatainanunknownformat,itcanat leastretrieveit.Thedatamaycontainenoughinformationtoallowauseroruser agenttomakesomeuseofit.WhenanagentdoesnothandleanewURIscheme, itcannotretrievearepresentation. Whendesigninganewdataformat,thepreferredmechanismtopromoteits deploymentontheWebistheInternetmediatype(seeRepresentationTypesand InternetMediaTypes(3.2)).Mediatypesalsoprovideameansforbuildingnew
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits 15/52

09/10/12

Architecture of the World Wide Web, Volume One

informationapplications,asdescribedinfuturedirectionsfordataformats(4.6).

2.5.URIOpacity
ItistemptingtoguessthenatureofaresourcebyinspectionofaURIthatidentifies it.However,theWebisdesignedsothatagentscommunicateresourceinformation statethroughrepresentations,notidentifiers.Ingeneral,onecannotdeterminethe typeofaresourcerepresentationbyinspectingaURIforthatresource.For example,the".html"attheendof"http://example.com/page.html"providesno guaranteethatrepresentationsoftheidentifiedresourcewillbeservedwiththe Internetmediatype"text/html".Thepublisherisfreetoallocateidentifiersand definehowtheyareserved.TheHTTPprotocoldoesnotconstraintheInternet mediatypebasedonthepathcomponentoftheURItheURIownerisfreeto configuretheservertoreturnarepresentationusingPNGoranyotherdataformat. Resourcestatemayevolveovertime.RequiringaURIownertopublishanewURI foreachchangeinresourcestatewouldleadtoasignificantnumberofbroken references.Forrobustness,Webarchitecturepromotesindependencebetweenan identifierandthestateoftheidentifiedresource.

Goodpractice:URIopacity AgentsmakinguseofURIsSHOULDNOTattempttoinferpropertiesof thereferencedresource. Inpractice,asmallnumberofinferencescanbemadebecausetheyareexplicitly licensedbytherelevantspecifications.Someoftheseinferencesarediscussedin thedetailsofretrievingarepresentation(3.1.1). TheexampleURIusedinthetravelscenario ("http://weather.example.com/oaxaca")suggeststoahumanreaderthatthe identifiedresourcehassomethingtodowiththeweatherinOaxaca.Asite reportingtheweatherinOaxacacouldjustaseasilybeidentifiedbytheURI "http://vjc.example.com/315".AndtheURI"http://weather.example.com/vancouver" mightidentifytheresource"myphotoalbum." Ontheotherhand,theURI"mailto:joe@example.com"indicatesthattheURIrefers toamailbox.The"mailto"URIschemespecificationauthorizesagentstoinferthat URIsofthisformidentifyInternetmailboxes. SomeURIassignmentauthoritiesdocumentandpublishtheirURIassignment policies.FormoreinformationaboutURIopacity,seeTAGissuesmetaDataInURI 31andsiteData36.

2.6.FragmentIdentifiers

Story WhenbrowsingtheXHTMLdocumentthatNadiareceivesasa
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits 16/52

09/10/12

Architecture of the World Wide Web, Volume One

representationoftheresourceidentifiedby "http://weather.example.com/oaxaca",shefindsthattheURI "http://weather.example.com/oaxaca#weekend"referstothepartofthe representationthatconveysinformationabouttheweekendoutlook.This URIincludesthefragmentidentifier"weekend"(thestringafterthe"#"). ThefragmentidentifiercomponentofaURIallowsindirectidentificationofa secondaryresourcebyreferencetoaprimaryresourceandadditionalidentifying information.Thesecondaryresourcemaybesomeportionorsubsetoftheprimary resource,someviewonrepresentationsoftheprimaryresource,orsomeother resourcedefinedordescribedbythoserepresentations.Theterms"primary resource"and"secondaryresource"aredefinedinsection3.5of[URI]. Thetermsprimaryandsecondaryinthiscontextdonotlimitthenatureofthe resourcetheyarenotclasses.Inthiscontext,primaryandsecondarysimply indicatethatthereisarelationshipbetweentheresourcesforthepurposesofone URI:theURIwithafragmentidentifier.Anyresourcecanbeidentifiedasa secondaryresource.ItmightalsobeidentifiedusingaURIwithoutafragment identifier,andaresourcemaybeidentifiedasasecondaryresourceviamultiple URIs.Thepurposeofthesetermsistoenablediscussionoftherelationship betweensuchresources,nottolimitthenatureofaresource. Theinterpretationoffragmentidentifiersisdiscussedinthesectiononmediatypes andfragmentidentifiersemantics(3.2.1). SeeTAGissueabstractComponentRefs37,whichconcernstheuseoffragment identifierswithnamespacenamestoidentifyabstractcomponents.

2.7.FutureDirectionsforIdentifiers
ThereremainopenquestionsregardingidentifiersontheWeb. 2.7.1.Internationalizedidentifiers Theintegrationofinternationalizedidentifiers(i.e.,composedofcharactersbeyond thoseallowedby[URI])intotheWebarchitectureisanimportantandopenissue. SeeTAGissueIRIEverywhere27fordiscussionaboutworkgoingoninthisarea. 2.7.2.AssertionthattwoURIsidentifythesameresource EmergingSemanticWebtechnologies,includingthe"WebOntologyLanguage (OWL)"[OWL10],defineRDFpropertiessuchass a m e A s toassertthattwoURIs identifythesameresourceori n v e r s e F u n c t i o n a l P r o p e r t y toimplyit.

3.Interaction
CommunicationbetweenagentsoveranetworkaboutresourcesinvolvesURIs, messages,anddata.TheWeb'sprotocols(includingHTTP,FTP,SOAP,NNTP, andSMTP)arebasedontheexchangeofmessages.Amessagemayinclude dataaswellasmetadataaboutaresource(suchasthe"Alternates"and"Vary" HTTPheaders),themessagedata,andthemessageitself(suchasthe"Transfer encoding"HTTPheader).Amessagemayevenincludemetadataaboutthe
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits 17/52

09/10/12

Architecture of the World Wide Web, Volume One

messagemetadata(formessageintegritychecks,forinstance).

Story Nadiafollowsahypertextlinklabeled"satelliteimage"expectingto retrieveasatellitephotooftheOaxacaregion.Thelinktothesatellite imageisanXHTMLlinkencodedas< a


h r e f = " h t t p : / / e x a m p l e . c o m / s a t i m a g e / o a x a c a " > s a t e l l i t ei m a g e < / a > .

Nadia'sbrowseranalyzestheURIanddeterminesthatitsschemeis "http".Thebrowserconfigurationdetermineshowitlocatestheidentified information,whichmightbeviaacacheofpriorretrievalactions,by contactinganintermediary(suchasaproxyserver),orbydirectaccess totheserveridentifiedbyaportionoftheURI.Inthisexample,the browseropensanetworkconnectiontoport80ontheserverat "example.com"andsendsa"GET"messageasspecifiedbytheHTTP protocol,requestingarepresentationoftheresource. Theserversendsaresponsemessagetothebrowser,onceagain accordingtotheHTTPprotocol.Themessageconsistsofseveral headersandaJPEGimage.Thebrowserreadstheheaders,learnsfrom the"ContentType"fieldthattheInternetmediatypeoftherepresentation is"image/jpeg",readsthesequenceofoctetsthatmakeupthe representationdata,andrenderstheimage. Thissectiondescribesthearchitecturalprinciplesandconstraintsregarding interactionsbetweenagents,includingsuchtopicsasnetworkprotocolsand interactionstyles,alongwithinteractionsbetweentheWebasasystemandthe peoplethatmakeuseofit.ThefactthattheWebisahighlydistributedsystem affectsarchitecturalconstraintsandassumptionsaboutinteractions.

3.1.UsingaURItoAccessaResource
AgentsmayuseaURItoaccessthereferencedresourcethisiscalled dereferencingtheURI.Accessmaytakemanyforms,includingretrievinga representationoftheresource(forinstance,byusingHTTPGETorHEAD),adding ormodifyingarepresentationoftheresource(forinstance,byusingHTTPPOSTor PUT,whichinsomecasesmaychangetheactualstateoftheresourceifthe submittedrepresentationsareinterpretedasinstructionstothatend),anddeleting someorallrepresentationsoftheresource(forinstance,byusingHTTPDELETE, whichinsomecasesmayresultinthedeletionoftheresourceitself). TheremaybemorethanonewaytoaccessaresourceforagivenURIapplication contextdetermineswhichaccessmethodanagentuses.Forinstance,abrowser mightuseHTTPGETtoretrievearepresentationofaresource,whereasa hypertextlinkcheckermightuseHTTPHEADonthesameURIsimplytoestablish whetherarepresentationisavailable.SomeURIschemessetexpectationsabout availableaccessmethods,others(suchastheURNscheme[RFC2141])donot. Section1.2.2of[URI]discussestheseparationofidentificationandinteractionin moredetail.Formoreinformationaboutrelationshipsbetweenmultipleaccess methodsandURIaddressability,seetheTAGfinding"URIs,Addressability,and theuseofHTTPGETandPOST".
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits 18/52

09/10/12

Architecture of the World Wide Web, Volume One

AlthoughmanyURIschemes(2.4)arenamedafterprotocols,thisdoesnotimply thatuseofsuchaURIwillnecessarilyresultinaccesstotheresourceviathe namedprotocol.EvenwhenanagentusesaURItoretrievearepresentation,that accessmightbethroughgateways,proxies,caches,andnameresolutionservices thatareindependentoftheprotocolassociatedwiththeschemename. ManyURIschemesdefineadefaultinteractionprotocolforattemptingaccessto theidentifiedresource.Thatinteractionprotocolisoftenthebasisforallocating identifierswithinthatscheme,justas"http"URIsaredefinedintermsofTCP basedHTTPservers.However,thisdoesnotimplythatallinteractionwithsuch resourcesislimitedtothedefaultinteractionprotocol.Forexample,information retrievalsystemsoftenmakeuseofproxiestointeractwithamultitudeofURI schemes,suchasHTTPproxiesbeingusedtoaccess"ftp"and"wais"resources. Proxiescanalsotoprovideenhancedservices,suchasannotationproxiesthat combinenormalinformationretrievalwithadditionalmetadataretrievaltoprovidea seamless,multidimensionalviewofresourcesusingthesameprotocolsanduser agentsasthenonannotatedWeb.Likewise,futureprotocolsmaybedefinedthat encompassourcurrentsystems,usingentirelydifferentinteractionmechanisms, withoutchangingtheexistingidentifierschemes.Seealso,principleoforthogonal specifications(5.1). 3.1.1.Detailsofretrievingarepresentation DereferencingaURIgenerallyinvolvesasuccessionofstepsasdescribedin multiplespecificationsandimplementedbytheagent.Thefollowingexample illustratestheseriesofspecificationsthatgovernstheprocesswhenauseragentis instructedtofollowahypertextlink(4.4)thatispartofanSVGdocument.Inthis example,theURIis"http://weather.example.com/oaxaca"andtheapplication contextcallsfortheuseragenttoretrieveandrenderarepresentationofthe identifiedresource. 1. SincetheURIispartofahypertextlinkinanSVGdocument,thefirstrelevant specificationistheSVG1.1Recommendation[SVG11].Section17.1ofthis specificationimportsthelinksemanticsdefinedinXLink1.0[XLink10]:"The remoteresource(thedestinationforthelink)isdefinedbyaURIspecifiedby theXLinkh r e f attributeonthe'a 'element."TheSVGspecificationgoesonto statethatinterpretationofana elementinvolvesretrievingarepresentationof aresource,identifiedbytheh r e f attributeintheXLinknamespace:"By activatingtheselinks(byclickingwiththemouse,throughkeyboardinput, voicecommands,etc.),usersmayvisittheseresources." 2. TheXLink1.0[XLink10]specification,whichdefinestheh r e f attributein section5.4,statesthat"ThevalueofthehrefattributemustbeaURI referenceasdefinedin[IETFRFC2396],ormustresultinaURIreference aftertheescapingproceduredescribedbelowisapplied." 3. TheURIspecification[URI]statesthat"EachURIbeginswithascheme namethatreferstoaspecificationforassigningidentifierswithinthat scheme."TheURIschemenameinthisexampleis"http". 4. [IANASchemes]statesthatthe"http"schemeisdefinedbytheHTTP/1.1 specification(RFC2616[RFC2616],section3.2.2). 5. InthisSVGcontext,theagentconstructsanHTTPGETrequest(persection 9.3of[RFC2616])toretrievetherepresentation. 6. Section6of[RFC2616]defineshowtheserverconstructsacorresponding responsemessage,includingthe'ContentType'field. 7. Section1.4of[RFC2616]states"HTTPcommunicationusuallytakesplace
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits 19/52

09/10/12

Architecture of the World Wide Web, Volume One

overTCP/IPconnections."Thisexampleaddressesneitherthatstepinthe processnorotherstepssuchasDomainNameSystem(DNS)resolution. 8. Theagentinterpretsthereturnedrepresentationaccordingtothedataformat specificationthatcorrespondstotherepresentation'sInternetMediaType (3.2)(thevalueoftheHTTP'ContentType')intherelevantIANAregistry [MEDIATYPEREG]. Preciselywhichrepresentation(s)areretrieveddependsonanumberoffactors, including: 1. WhethertheURIownermakesavailableanyrepresentationsatall 2. Whethertheagentmakingtherequesthasaccessprivilegesforthose representations(seethesectiononlinkingandaccesscontrol(3.5.2)) 3. IftheURIownerhasprovidedmorethanonerepresentation(indifferent formatssuchasHTML,PNG,orRDFindifferentlanguagessuchasEnglish andSpanishortransformeddynamicallyaccordingtothehardwareor softwarecapabilitiesoftherecipient),theresultingrepresentationmay dependonnegotiationbetweentheuseragentandserver. 4. Thetimeoftherequesttheworldchangesovertime,sorepresentationsof resourcesarealsolikelytochangeovertime. Assumingthatarepresentationhasbeensuccessfullyretrieved,theexpressive poweroftherepresentation'sformatwillaffecthowpreciselytherepresentation providercommunicatesresourcestate.Iftherepresentationcommunicatesthe stateoftheresourceinaccurately,thisinaccuracyorambiguitymayleadto confusionamongusersaboutwhattheresourceis.Ifdifferentusersreachdifferent conclusionsaboutwhattheresourceis,theymayinterpretthisasaURIcollision (2.2.1).Somecommunities,suchastheonesdevelopingtheSemanticWeb,seek toprovideaframeworkforaccuratelycommunicatingthesemanticsofaresourcein amachinereadableway.Machinereadablesemanticsmayalleviatesomeofthe ambiguityassociatedwithnaturallanguagedescriptionsofresources.

3.2.RepresentationTypesandInternetMediaTypes
Arepresentationisdatathatencodesinformationaboutresourcestate. Representationsdonotnecessarilydescribetheresource,orportrayalikenessof theresource,orrepresenttheresourceinothersensesoftheword"represent". Representationsofaresourcemaybesentorreceivedusinginteractionprotocols. Theseprotocolsinturndeterminetheforminwhichrepresentationsareconveyed ontheWeb.HTTP,forexample,providesfortransmissionofrepresentationsas octetstreamstypedusingInternetmediatypes[RFC2046]. JustasitisimportanttoreuseexistingURIschemeswheneverpossible,thereare significantbenefitstousingmediatypedoctetstreamsforrepresentationsevenin theunusualcasewhereanewURIschemeandassociatedprotocolistobe defined.Forexample,iftheOaxacaweatherwereconveyedtoNadia'sbrowser usingaprotocolotherthanHTTP,thensoftwaretorenderformatssuchas text/xhmtl+xmlandimage/pngwouldstillbeusableifthenewprotocolsupported transmissionofthosetypes.Thisisanexampleoftheprincipleoforthogonal specifications(5.1).

Goodpractice:Reuserepresentationformats
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits 20/52

09/10/12

Architecture of the World Wide Web, Volume One

NewprotocolscreatedfortheWebSHOULDtransmitrepresentationsas octetstreamstypedbyInternetmediatypes. TheInternetmediatypemechanismdoeshavesomelimitations.Forinstance, mediatypestringsdonotsupportversioning(4.2.1)orotherparameters.SeeTAG issuesuriMediaType9andmediaTypeManagement45whichconcernaspectsof themediatypemechanism. 3.2.1.Representationtypesandfragmentidentifiersemantics TheInternetMediaTypedefinesthesyntaxandsemanticsofthefragmentidentifier (introducedinFragmentIdentifiers(2.6)),ifany,thatmaybeusedinconjunction witharepresentation.

Story InoneofhisXHTMLpages,Dirkcreatesahypertextlinktoanimage thatNadiahaspublishedontheWeb.Hecreatesahypertextlinkwith< a h r e f = " h t t p : / / w w w . e x a m p l e . c o m / i m a g e s / n a d i a # h a t " > N a d i a ' sh a t < / a > . EmmaviewsDirk'sXHTMLpageinherWebbrowserandfollowsthe link.TheHTMLimplementationinherbrowserremovesthefragment fromtheURIandrequeststheimage "http://www.example.com/images/nadia".NadiaservesanSVG representationoftheimage(withInternetmediatype"image/svg+xml"). Emma'sWebbrowserstartsupanSVGimplementationtoviewthe image.ItpassesittheoriginalURIincludingthefragment, "http://www.example.com/images/nadia#hat"tothisimplementation, causingaviewofthehattobedisplayedratherthanthecomplete image. NotethattheHTMLimplementationinEmma'sbrowserdidnotneedtounderstand thesyntaxorsemanticsoftheSVGfragment(nordoestheSVGimplementation havetounderstandHTML,WebCGM,RDF...fragmentsyntaxorsemanticsit merelyhadtorecognizethe#delimiterfromtheURIsyntax[URI]andremovethe fragmentwhenaccessingtheresource).Thisorthogonality(5.1)isanimportant featureofWebarchitectureitiswhatenabledEmma'sbrowsertoprovideauseful servicewithoutrequiringanupgrade. Thesemanticsofafragmentidentifieraredefinedbythesetofrepresentationsthat mightresultfromaretrievalactionontheprimaryresource.Thefragment'sformat andresolutionarethereforedependentonthetypeofapotentiallyretrieved representation,eventhoughsucharetrievalisonlyperformediftheURIis dereferenced.Ifnosuchrepresentationexists,thenthesemanticsofthefragment areconsideredunknownand,effectively,unconstrained.Fragmentidentifier semanticsareorthogonaltoURIschemesandthuscannotberedefinedbyURI schemespecifications. Interpretationofthefragmentidentifierisperformedsolelybytheagentthat dereferencesaURIthefragmentidentifierisnotpassedtoothersystemsduring theprocessofretrieval.ThismeansthatsomeintermediariesinWebarchitecture
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits 21/52

09/10/12

Architecture of the World Wide Web, Volume One

(suchasproxies)havenointeractionwithfragmentidentifiersandthatredirection (inHTTP[RFC2616],forexample)doesnotaccountforfragments. 3.2.2.Fragmentidentifiersandcontentnegotiation Contentnegotiationreferstothepracticeofmakingavailablemultiple representationsviathesameURI.Negotiationbetweentherequestingagentand theserverdetermineswhichrepresentationisserved(usuallywiththegoalof servingthe"best"representationareceivingagentcanprocess).HTTPisan exampleofaprotocolthatenablesrepresentationproviderstousecontent negotiation. Individualdataformatsmaydefinetheirownrulesforuseofthefragmentidentifier syntaxforspecifyingdifferenttypesofsubsets,views,orexternalreferencesthat areidentifiableassecondaryresourcesbythatmediatype.Therefore, representationprovidersmustmanagecontentnegotiationcarefullywhenused withaURIthatcontainsafragmentidentifier.Consideranexamplewherethe owneroftheURI"http://weather.example.com/oaxaca/map#zicatela"usescontent negotiationtoservetworepresentationsoftheidentifiedresource.Threesituations canarise: 1. Theinterpretationof"zicatela"isdefinedconsistentlybybothdataformat specifications.Therepresentationproviderdecideswhendefinitionsof fragmentidentifiersemanticsarearesufficientlyconsistent. 2. Theinterpretationof"zicatela"isdefinedinconsistentlybythedataformat specifications. 3. Theinterpretationof"zicatela"isdefinedinonedataformatspecificationbut nottheother. Thefirstsituationconsistentsemanticsposesnoproblem. Thesecondcaseisaservermanagementerror:representationprovidersmustnot usecontentnegotiationtoserverepresentationformatsthathaveinconsistent fragmentidentifiersemantics.ThissituationalsoleadstoURIcollision(2.2.1). Thethirdcaseisnotaservermanagementerror.ItisameansbywhichtheWeb cangrow.BecausetheWebisadistributedsysteminwhichformatsandagents aredeployedinanonuniformmanner,Webarchitecturedoesnotconstrain authorstoonlyuse"lowestcommondenominator"formats.Contentauthorsmay takeadvantageofnewdataformatswhilestillensuringreasonablebackward compatibilityforagentsthatdonotyetimplementthem. Incasethree,behaviorbythereceivingagentshouldvarydependingonwhether thenegotiatedformatdefinesfragmentidentifiersemantics.Whenareceiveddata formatdoesnotdefinefragmentidentifiersemantics,theagentshouldnotperform silenterrorrecoveryunlesstheuserhasgivenconsentsee[CUAP]foradditional suggestedagentbehaviorinthiscase. SeerelatedTAGissueRDFinXHTML35.

3.3.InconsistenciesbetweenRepresentationDataandMetadata
Successfulcommunicationbetweentwopartiesdependsonareasonablyshared understandingofthesemanticsofexchangedmessages,bothdataandmetadata.
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits 22/52

09/10/12

Architecture of the World Wide Web, Volume One

Attimes,theremaybeinconsistenciesbetweenamessagesender'sdataand metadata.Examples,observedinpractice,ofinconsistenciesbetween representationdataandmetadatainclude: Theactualcharacterencodingofarepresentation(e.g.,"iso88591", specifiedbythee n c o d i n g attributeinanXMLdeclaration)isinconsistentwith thecharsetparameterintherepresentationmetadata(e.g.,"utf8",specified bythe'ContentType'fieldinanHTTPheader). Thenamespace(4.5.3)oftherootelementofXMLrepresentationdata(e.g., asspecifiedbythe"xmlns"attribute)isinconsistentwiththevalueofthe 'ContentType'fieldinanHTTPheader. Ontheotherhand,thereisnoinconsistencyinservingHTMLcontentwiththe mediatype"text/plain",forexample,asthiscombinationislicensedby specifications. Receivingagentsshoulddetectprotocolinconsistenciesandperformpropererror recovery.

Constraint:Datametadatainconsistency AgentsMUSTNOTignoremessagemetadatawithouttheconsentofthe user. Thus,forexample,ifthepartiesresponsiblefor"weather.example.com"mistakenly labelthesatellitephotoofOaxacaas"image/gif"insteadof"image/jpeg",andif Nadia'sbrowserdetectsaproblem,Nadia'sbrowsermustnotignoretheproblem (e.g.,bysimplyrenderingtheJPEGimage)withoutNadia'sconsent.Nadia's browsercannotifyNadiaoftheproblemornotifyNadiaandtakecorrectiveaction. Furthermore,representationproviderscanhelpreducetheriskofinconsistencies throughcarefulassignmentofrepresentationmetadata(especiallythatwhich appliesacrossrepresentations).ThesectiononmediatypesforXML(4.5.7) presentsanexampleofreducingtheriskoferrorbyprovidingnometadataabout characterencodingwhenservingXML. Theaccuracyofmetadatareliesontheserveradministrators,theauthorsof representations,andthesoftwarethattheyuse.Practically,thecapabilitiesofthe toolsandthesocialrelationshipsmaybethelimitingfactors. Theaccuracyoftheseandothermetadatafieldsisjustasimportantfordynamic Webresources,wherealittlebitofthoughtandprogrammingcanoftenensure correctmetadataforahugenumberofresources. Oftenthereisaseparationofcontrolbetweentheuserswhocreaterepresentations ofresourcesandtheservermanagerswhomaintaintheWebsitesoftware.Given thatitisgenerallytheWebsitesoftwarethatprovidesthemetadataassociatedwith aresource,itfollowsthatcoordinationbetweentheservermanagersandcontent creatorsisrequired.

www.w3.org/TR/2004/RECwebarch20041215/#uribenefits

23/52

09/10/12

Architecture of the World Wide Web, Volume One

Goodpractice:Metadataassociation ServermanagersSHOULDallowrepresentationcreatorstocontrolthe metadataassociatedwiththeirrepresentations. Inparticular,contentcreatorsneedtobeabletocontrolthecontenttype(for extensibility)andthecharacterencoding(forproperinternationalization). TheTAGfinding"AuthoritativeMetadata"discussesinmoredetailhowtohandle data/metadatainconsistencyandhowserverconfigurationcanbeusedtoavoidit.

3.4.SafeInteractions
Nadia'sretrievalofweatherinformation(anexampleofareadonlyqueryor lookup)qualifiesasa"safe"interactionasafeinteractionisonewheretheagent doesnotincuranyobligationbeyondtheinteraction.Anagentmayincuran obligationthroughothermeans(suchasbysigningacontract).Ifanagentdoesnot haveanobligationbeforeasafeinteraction,itdoesnothavethatobligation afterwards. OtherWebinteractionsresembleordersmorethanqueries.Theseunsafe interactionsmaycauseachangetothestateofaresourceandtheusermaybe heldresponsiblefortheconsequencesoftheseinteractions.Unsafeinteractions includesubscribingtoanewsletter,postingtoalist,ormodifyingadatabase.Note: Inthiscontext,theword"unsafe"doesnotnecessarilymean"dangerous"theterm "safe"isusedinsection9.1.1of[RFC2616]and"unsafe"isthenaturalopposite.

Story NadiadecidestobookavacationtoOaxacaat"booking.example.com." Sheentersdataintoaseriesofonlineformsandisultimatelyaskedfor creditcardinformationtopurchasetheairlinetickets.Sheprovidesthis informationinanotherform.Whenshepressesthe"Purchase"button, herbrowseropensanothernetworkconnectiontotheserverat "booking.example.com"andsendsamessagecomposedofformdata usingthePOSTmethod.ThisisanunsafeinteractionNadiawishesto changethestateofthesystembyexchangingmoneyforairlinetickets. TheserverreadsthePOSTrequest,andafterperformingthebooking transactionreturnsamessagetoNadia'sbrowserthatcontainsa representationoftheresultsofNadia'srequest.Therepresentationdata isinXHTMLsothatitcanbesavedorprintedoutforNadia'srecords. NotethatneitherthedatatransmittedwiththePOSTnorthedata receivedintheresponsenecessarilycorrespondtoanyresource identifiedbyaURI. Safeinteractionsareimportantbecausetheseareinteractionswhereuserscan browsewithconfidenceandwhereagents(includingsearchenginesandbrowsers
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits

thatprecachedatafortheuser)canfollowhypertextlinkssafely.Users(oragents

24/52

09/10/12

Architecture of the World Wide Web, Volume One

thatprecachedatafortheuser)canfollowhypertextlinkssafely.Users(oragents actingontheirbehalf)donotcommitthemselvestoanythingbyqueryinga resourceorfollowingahypertextlink.

Principle:Saferetrieval Agentsdonotincurobligationsbyretrievingarepresentation. Forinstance,itisincorrecttopublishaURIthat,whenfollowedaspartofa hypertextlink,subscribesausertoamailinglist.Rememberthatsearchengines mayfollowsuchhypertextlinks. ThefactthatHTTPGET,theaccessmethodmostoftenusedwhenfollowinga hypertextlink,issafedoesnotimplythatallsafeinteractionsmustbedonethrough HTTPGET.Attimes,theremaybegoodreasons(suchasconfidentiality requirementsorpracticallimitsonURIlength)toconductanotherwisesafe operationusingamechanismgenerallyreservedforunsafeoperations(e.g.,HTTP POST). FormoreinformationaboutsafeandunsafeoperationsusingHTTPGETand POST,andhandlingsecurityconcernsaroundtheuseofHTTPGET,seetheTAG finding"URIs,Addressability,andtheuseofHTTPGETandPOST". 3.4.1.Unsafeinteractionsandaccountability

Story Nadiapaysforherairlineticketsonline(throughaPOSTinteractionas describedabove).ShereceivesaWebpagewithconfirmation informationandwishestobookmarkitsothatshecanrefertoitwhen shecalculatesherexpenses.AlthoughNadiacanprintouttheresults,or savethemtoafile,shewouldalsoliketobookmarkthem. Transactionrequestsandresultsarevaluableresources,andlikeallvaluable resources,itisusefultobeabletorefertothemwithapersistentURI(3.5.1). However,inpractice,Nadiacannotbookmarkhercommitmenttopay(expressed viathePOSTrequest)ortheairlinecompany'sacknowledgmentandcommitment toprovideherwithaflight(expressedviatheresponsetothePOST). TherearewaystoprovidepersistentURIsfortransactionrequestsandtheirresults. Fortransactionrequests,useragentscanprovideaninterfaceformanaging transactionswheretheuseragenthasincurredanobligationonbehalfoftheuser. Fortransactionresults,HTTPallowsrepresentationproviderstoassociateaURI withtheresultsofanHTTPPOSTrequestusingthe"ContentLocation"header (describedinsection14.14of[RFC2616]).

3.5.RepresentationManagement
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits 25/52

09/10/12

Architecture of the World Wide Web, Volume One

Story SinceNadiafindstheOaxacaweathersiteuseful,sheemailsareview toherfriendDirkrecommendingthathecheckout 'http://weather.example.com/oaxaca'.Dirkclicksontheresulting hypertextlinkintheemailhereceivesandisfrustratedbya404(not found).Dirktriesagainthenextdayandreceivesarepresentationwith "news"thatistwoweeksold.Hetriesonemoretimethenextdayonlyto receivearepresentationthatclaimsthattheweatherinOaxacaissunny, eventhoughhisfriendsinOaxacatellhimbyphonethatinfactitis raining.DirkandNadiaconcludethattheURIownersareunreliableor unpredictable.AlthoughtheURIownerhaschosentheWebasa communicationmedium,theownerhaslosttwocustomersdueto ineffectiverepresentationmanagement. AURIownermaysupplyzeroormoreauthoritativerepresentationsoftheresource identifiedbythatURI.Thereisabenefittothecommunityinproviding representations.

Goodpractice:Availablerepresentation AURIownerSHOULDproviderepresentationsoftheresourceit identifies Forexample,ownersofXMLnamespaceURIsshouldusethemtoidentifya namespacedocument(4.5.4). Justbecauserepresentationsareavailabledoesnotmeanthatitisalways desirabletoretrievethem.Infact,insomecasestheoppositeistrue.

Principle:Referencedoesnotimplydereference AnapplicationdeveloperorspecificationauthorSHOULDNOTrequire networkedretrievalofrepresentationseachtimetheyarereferenced. DereferencingaURIhasa(potentiallysignificant)costincomputingand bandwidthresources,mayhavesecurityimplications,andmayimposesignificant latencyonthedereferencingapplication.DereferencingURIsshouldbeavoided exceptwhennecessary. Thefollowingsectionsdiscusssomeaspectsofrepresentationmanagement, includingpromotingURIpersistence(3.5.1),managingaccesstoresources (3.5.2),andsupportingnavigation(3.5.3). 3.5.1.URIpersistence
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits 26/52

09/10/12

Architecture of the World Wide Web, Volume One

Asisthecasewithmanyhumaninteractions,confidenceininteractionsviathe Webdependsonstabilityandpredictability.Foraninformationresource, persistencedependsontheconsistencyofrepresentations.Therepresentation providerdecideswhenrepresentationsaresufficientlyconsistent(althoughthat determinationgenerallytakesuserexpectationsintoaccount). Althoughpersistenceinthiscaseisobservableasaresultofrepresentation retrieval,thetermURIpersistenceisusedtodescribethedesirablepropertythat, onceassociatedwitharesource,aURIshouldcontinueindefinitelytorefertothat resource.

Goodpractice:Consistentrepresentation AURIownerSHOULDproviderepresentationsoftheidentifiedresource consistentlyandpredictably. URIpersistenceisamatterofpolicyandcommitmentonthepartoftheURIowner. ThechoiceofaparticularURIschemeprovidesnoguaranteethatthoseURIswill bepersistentorthattheywillnotbepersistent. HTTP[RFC2616]hasbeendesignedtohelpmanageURIpersistence.For example,HTTPredirection(usingthe3xxresponsecodes)permitsserverstotell anagentthatfurtheractionneedstobetakenbytheagentinordertofulfillthe request(forexample,anewURIisassociatedwiththeresource). Inaddition,contentnegotiationalsopromotesconsistency,asasitemanagerisnot requiredtodefinenewURIswhenaddingsupportforanewformatspecification. Protocolsthatdonotsupportcontentnegotiation(suchasFTP)requireanew identifierwhenanewdataformatisintroduced.Improperuseofcontentnegotiation canleadtoinconsistentrepresentations. FormorediscussionaboutURIpersistence,see[Cool]. 3.5.2.Linkingandaccesscontrol Itisreasonabletolimitaccesstoaresource(forcommercialorsecurityreasons,for example),butmerelyidentifyingtheresourceislikereferringtoabookbytitle.In exceptionalcircumstances,peoplemayhaveagreedtokeeptitlesorURIs confidential(forexample,abookauthorandapublishermayagreetokeeptheURI ofpagecontainingadditionalmaterialsecretuntilafterthebookispublished), otherwisetheyarefreetoexchangethem. Asananalogy:Theownersofabuildingmighthaveapolicythatthepublicmay onlyenterthebuildingviathemainfrontdoor,andonlyduringbusinesshours. Peoplewhoworkinthebuildingandwhomakedeliveriestoitmightuseother doorsasappropriate.Suchapolicywouldbeenforcedbyacombinationofsecurity personnelandmechanicaldevicessuchaslocksandpasscards.Onewouldnot enforcethispolicybyhidingsomeofthebuildingentrances,norbyrequesting legislationrequiringtheuseofthefrontdoorandforbiddinganyonetorevealthe factthatthereareotherdoorstothebuilding.
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits 27/52

09/10/12

Architecture of the World Wide Web, Volume One

Story NadiasendstoDirktheURIofthecurrentarticlesheisreading.Withhis browser,Dirkfollowsthehypertextlinkandisaskedtoenterhis subscriberusernameandpassword.SinceDirkisalsoasubscriberto servicesprovidedby"weather.example.com,"hecanaccessthesame informationasNadia.Thus,theauthorityfor"weather.example.com"can limitaccesstoauthorizedpartiesandstillprovidethebenefitsofURIs. TheWebprovidesseveralmechanismstocontrolaccesstoresourcesthese mechanismsdonotrelyonhidingorsuppressingURIsforthoseresources.For moreinformation,seetheTAGfinding"'DeepLinking'intheWorldWideWeb". 3.5.3.SupportingNavigation ItisastrengthofWebArchitecturethatlinkscanbemadeandsharedauserwho hasfoundaninterestingpartoftheWebcansharethisexperiencejustby republishingaURI.

Story NadiaandDirkwanttovisittheMuseumofWeatherForecastingin Oaxaca.Nadiagoesto"http://maps.example.com",locatesthemuseum, andmailstheURI"http://maps.example.com/oaxaca? lat=17.065lon=96.716scale=6"toDirk.Dirkgoesto "http://mymaps.example.com",locatesthemuseum,andmailstheURI "http://mymaps.example.com/geo?sessionID=765345userID=Dirk"to Nadia.DirkreadsNadia'semailandisabletofollowthelinktothemap. NadiareadsDirk'semail,followsthelink,andreceivesanerror message'Nosuchsession/user'.Nadiahastostartagainfrom "http://mymaps.example.com"andfindthemuseumlocationoncemore. Forresourcesthataregeneratedondemand,machinegenerationofURIsis common.Forresourcesthatmightusefullybebookmarkedforlaterperusal,or sharedwithothers,servermanagersshouldavoidneedlesslyrestrictingthe reusabilityofsuchURIs.Iftheintentionistorestrictinformationtoaparticularuser, asmightbethecaseinahomebankingapplicationforexample,designersshould useappropriateaccesscontrol(3.5.2)mechanisms. InteractionsconductedwithHTTPPOST(whereHTTPGETcouldhavebeen used)alsolimitnavigationpossibilities.Theusercannotcreateabookmarkor sharetheURIbecauseHTTPPOSTtransactionsdonottypicallyresultina differentURIastheuserinteractswiththesite.

3.6.FutureDirectionsforInteraction
ThereremainopenquestionsregardingWebinteractions.TheTAGexpectsfuture versionsofthisdocumenttoaddressinmoredetailtherelationshipbetweenthe architecturedescribedherein,WebServices,peertopeersystems,instant
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits 28/52

09/10/12

Architecture of the World Wide Web, Volume One

messagingsystems(suchas[RFC3920]),streamingaudio(suchasRTSP [RFC2326]),andvoiceoverIP(suchasSIP[RFC3261]).

4.DataFormats
Adataformatspecification(forexample,forXHTML,RDF/XML,SMIL,XLink,CSS, andPNG)embodiesanagreementonthecorrectinterpretationofrepresentation data.ThefirstdataformatusedontheWebwasHTML.Sincethen,dataformats havegrowninnumber.Webarchitecturedoesnotconstrainwhichdataformats contentproviderscanuse.Thisflexibilityisimportantbecausethereisconstant evolutioninapplications,resultinginnewdataformatsandrefinementsofexisting formats.AlthoughWebarchitectureallowsforthedeploymentofnewdataformats, thecreationanddeploymentofnewformats(andagentsabletohandlethem)is expensive.Thus,beforeinventinganewdataformat(or"meta"formatsuchas XML),designersshouldcarefullyconsiderreusingonethatisalreadyavailable. Foradataformattobeusefullyinteroperablebetweentwoparties,thepartiesmust agree(toareasonableextent)aboutitssyntaxandsemantics.Shared understandingofadataformatpromotesinteroperabilitybutdoesnotimply constraintsonusageforinstance,asenderofdatacannotcountonbeingableto constrainthebehaviorofadatareceiver. Belowwedescribesomecharacteristicsofadataformatthatfacilitateintegration intoWebarchitecture.Thisdocumentdoesnotaddressgenerallybeneficial characteristicsofaspecificationsuchasreadability,simplicity,attentionto programmergoals,attentiontouserneeds,accessibility,norinternationalization. Thesectiononarchitecturalspecifications(7.1)includesreferencestoadditional formatspecificationguidelines.

4.1.BinaryandTextualDataFormats
Binarydataformatsarethoseinwhichportionsofthedataareencodedfordirect usebycomputerprocessors,forexample32bitlittleendiantwo'scomplementand 64bitIEEEdoubleprecisionfloatingpoint.Theportionsofdatasorepresented includenumericvalues,pointers,andcompresseddataofallsorts. Atextualdataformatisoneinwhichthedataisspecifiedinadefinedencodingas asequenceofcharacters.HTML,Internetemail,andallXMLbasedformats(4.5) aretextual.Increasingly,internationalizedtextualdataformatsrefertotheUnicode repertoire[UNICODE]forcharacterdefinitions. Ifadataformatistextual,asdefinedinthissection,thatdoesnotimplythatit shouldbeservedwithamediatypebeginningwith"text/".AlthoughXMLbased formatsaretextual,manyXMLbasedformatsdonotconsistprimarilyofphrasesin naturallanguage.SeethesectiononmediatypesforXML(4.5.7)forissuesthat arisewhen"text/"isusedinconjunctionwithanXMLbasedformat. Inprinciple,alldatacanberepresentedusingtextualformats.Inpractice,some typesofcontent(e.g.,audioandvideo)aregenerallyrepresentedusingbinary formats. Thetradeoffsbetweenbinaryandtextualdataformatsarecomplexand applicationdependent.Binaryformatscanbesubstantiallymorecompact, particularlyforcomplexpointerrichdatastructures.Also,theycanbeconsumed
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits 29/52

09/10/12

Architecture of the World Wide Web, Volume One

morerapidlybyagentsinthosecaseswheretheycanbeloadedintomemoryand usedwithlittleornoconversion.Note,however,thatsuchcasesarerelatively uncommonassuchdirectusemayopenthedoortosecurityissuesthatcanonly practicallybeaddressedbyexaminingeveryaspectofthedatastructureindetail. Textualformatsareusuallymoreportableandinteroperable.Textualformatsalso havetheconsiderableadvantagethattheycanbedirectlyreadbyhumanbeings (andunderstood,givensufficientdocumentation).Thiscansimplifythetasksof creatingandmaintainingsoftware,andallowthedirectinterventionofhumansin theprocessingchainwithoutrecoursetotoolsmorecomplexthantheubiquitous texteditor.Finally,itsimplifiesthenecessaryhumantaskoflearningaboutnew dataformatsthisiscalledthe"viewsource"effect. Itisimportanttoemphasizethatintuitionastosuchmattersasdatasizeand processingspeedisnotareliableguideindataformatdesignquantitativestudies areessentialtoacorrectunderstandingofthetradeoffs.Therefore,designersofa dataformatspecificationshouldmakeaconsideredchoicebetweenbinaryand textualformatdesign. SeeTAGissuebinaryXML30.

4.2.VersioningandExtensibility
Inaperfectworld,languagedesignerswouldinventlanguagesthatperfectlymet therequirementspresentedtothem,therequirementswouldbeaperfectmodelof theworld,theywouldneverchangeovertime,andallimplementationswouldbe perfectlyinteroperablebecausethespecificationswouldhavenovariability. Intherealworld,languagedesignersimperfectlyaddresstherequirementsasthey interpretthem,therequirementsinaccuratelymodeltheworld,conflicting requirementsarepresented,andtheychangeovertime.Asaresult,designers negotiatewithusers,makecompromises,andoftenintroduceextensibility mechanismssothatitispossibletoworkaroundproblemsintheshortterm.Inthe longterm,theyproducemultipleversionsoftheirlanguages,astheproblem,and theirunderstandingofit,evolve.Theresultingvariabilityinspecifications, languages,andimplementationsintroducesinteroperabilitycosts. Extensibilityandversioningarestrategiestohelpmanagethenaturalevolutionof informationontheWebandtechnologiesusedtorepresentthatinformation.For moreinformationabouthowthesestrategiesintroducevariabilityandhowthat variabilityimpactsinteroperability,seeVariabilityinSpecifications. SeeTAGissueXMLVersioning41,whichconcernsgoodpracticesfordesigning extensibleXMLlanguagesandforhandlingversioning.Seealso"Web Architecture:ExtensibleLanguages"[EXTLANG]. 4.2.1.Versioning Thereistypicallya(long)transitionperiodduringwhichmultipleversionsofa format,protocol,oragentaresimultaneouslyinuse.

Goodpractice:Versioninformation
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits 30/52

09/10/12

Architecture of the World Wide Web, Volume One

AdataformatspecificationSHOULDprovideforversioninformation. 4.2.2.VersioningandXMLnamespacepolicy

Story NadiaandDirkaredesigninganXMLdataformattoencodedataabout thefilmindustry.TheyprovideforextensibilitybyusingXML namespacesandcreatingaschemathatallowstheinclusion,incertain places,ofelementsfromanynamespace.Whentheyrevisetheirformat, Nadiaproposesanewoptionall a n g attributeonthef i l m element.Dirk feelsthatsuchachangerequiresthemtoassignanewnamespace name,whichmightrequirechangestodeployedsoftware.Nadia explainstoDirkthattheirchoiceofextensibilitystrategyinconjunction withtheirnamespacepolicyallowscertainchangesthatdonotaffect conformanceofexistingcontentandsoftware,andthusnochangetothe namespaceidentifierisrequired.Theychosethispolicytohelpthem meettheirgoalsofreducingthecostofchange. DirkandNadiahavechosenaparticularnamespacechangepolicythatallows themtoavoidchangingthenamespacenamewhenevertheymakechangesthat donotaffectconformanceofdeployedcontentandsoftware.Theymighthave chosenadifferentpolicy,forexamplethatanynewelementorattributehasto belongtoanamespaceotherthantheoriginalone.Whateverthechosenpolicy,it shouldsetclearexpectationsforusersoftheformat. Ingeneral,changingthenamespacenameofanelementcompletelychangesthe elementname.If"a"and"b"areboundtotwodifferentURIs,a : e l e m e n t and b : e l e m e n t areasdistinctasa : e i e i o anda : x y z z y .Practicallyspeaking,thismeans thatdeployedapplicationswillhavetobeupgradedinordertorecognizethenew languagethecostofthisupgrademaybeveryhigh. Itfollowsthattherearesignificanttradeoffstobeconsideredwhendecidingona namespacechangepolicy.Ifavocabularyhasnoextensibilitypoints(thatis,ifit doesnotallowelementsorattributesfromforeignnamespacesorhavea mechanismfordealingwithunrecognizednamesfromthesamenamespace),it maybeabsolutelynecessarytochangethenamespacename.Languagesthat allowsomeformofextensibilitywithoutrequiringachangetothenamespacename aremorelikelytoevolvegracefully.

Goodpractice:Namespacepolicy AnXMLformatspecificationSHOULDincludeinformationaboutchange policiesforXMLnamespaces. Asanexampleofachangepolicydesignedtoreflectthevariablestabilityofa namespace,considertheW3CnamespacepolicyfordocumentsontheW3C


www.w3.org/TR/2004/RECwebarch20041215/#uribenefits

Recommendationtrack.ThepolicysetsexpectationsthattheWorkingGroup

31/52

09/10/12

Architecture of the World Wide Web, Volume One

Recommendationtrack.ThepolicysetsexpectationsthattheWorkingGroup responsibleforthenamespacemaymodifyitinanywayuntilacertainpointinthe process("CandidateRecommendation")atwhichpointW3Cconstrainsthesetof possiblechangestothenamespaceinordertopromotestableimplementations. NotethatsincenamespacenamesareURIs,theownerofanamespaceURIhas theauthoritytodecidethenamespacechangepolicy. 4.2.3.Extensibility Requirementschangeovertime.Successfultechnologiesareadoptedand adaptedbynewusers.Designerscanfacilitatethetransitionprocessbymaking carefulchoicesaboutextensibilityduringthedesignofalanguageorprotocol specification. Inmakingthesechoices,thedesignersmustweighthetradeoffsbetween extensibility,simplicity,andvariability.Alanguagewithoutextensibility mechanismsmaybesimplerandlessvariable,improvinginitialinteroperability. However,it'slikelythatchangestothatlanguagewillbemoredifficult,possibly morecomplexandmorevariable,thaniftheinitialdesignhadprovidedsuch mechanisms.Thismaydecreaseinteroperabilityoverthelongterm.

Goodpractice:Extensibilitymechanisms AspecificationSHOULDprovidemechanismsthatallowanypartyto createextensions. Extensibilityintroducesvariabilitywhichhasanimpactoninteroperability. However,languagesthathavenoextensibilitymechanismsmaybeextendedinad hocwaysthatimpactinteroperabilityaswell.Onekeycriterionofthemechanisms providedbylanguagedesignersisthattheyallowtheextendedlanguagesto remaininconformancewiththeoriginalspecification,increasingthelikelihoodof interoperability.

Goodpractice:Extensibilityconformance ExtensibilityMUSTNOTinterferewithconformancetotheoriginal specification. Applicationneedsdeterminethemostappropriateextensionstrategyfora specification.Forexample,applicationsdesignedtooperateinclosed environmentsmayallowspecificationdesignerstodefineaversioningstrategythat wouldbeimpracticalatthescaleoftheWeb.

Goodpractice:Unknownextensions
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits 32/52

09/10/12

Architecture of the World Wide Web, Volume One

AspecificationSHOULDspecifyagentbehaviorinthefaceof unrecognizedextensions. Twostrategieshaveemergedasbeingparticularlyuseful: 1. "Mustignore":Theagentignoresanycontentitdoesnotrecognize. 2. "Mustunderstand":Theagenttreatsunrecognizedmarkupasanerror condition. Apowerfuldesignapproachisforthelanguagetoalloweitherformofextension, buttodistinguishexplicitlybetweentheminthesyntax. Additionalstrategiesincludepromptingtheuserformoreinputandautomatically retrievingdatafromavailablehypertextlinks.Morecomplexstrategiesarealso possible,includingmixingstrategies.Forinstance,alanguagecaninclude mechanismsforoverridingstandardbehavior.Thus,adataformatcanspecify "mustignore"semanticsbutalsoallowforextensionsthatoverridethatsemantics inlightofapplicationneeds(forinstance,with"mustunderstand"semanticsfora particularextension). Extensibilityisnotfree.Providinghooksforextensibilityisoneofmany requirementstobefactoredintothecostsoflanguagedesign.Experiencesuggests thatthelongtermbenefitsofawelldesignedextensibilitymechanismgenerally outweighthecosts. SeeD.3ExtensibilityandExtensionsin[QA]. 4.2.4.Compositionofdataformats Manymoderndataformatincludemechanismsforcomposition.Forexample: Itispossibletoembedtextcommentsinsomeimageformats,suchas JPEG/JFIF.Althoughthesecommentsareembeddedinthecontainingdata, theyarenotintendedtoaffectthedisplayoftheimage. TherearecontainerformatssuchasSOAPwhichfullyexpectcontentfrom multiplenamespacesbutwhichprovideanoverallsemanticrelationshipof messageenvelopeandpayload. ThesemanticsofcombiningRDFdocumentscontainingmultiple vocabulariesarewelldefined. Inprinciple,theserelationshipscanbemixedandnestedarbitrarily.ASOAP message,forexample,cancontainanSVGimagethatcontainsanRDFcomment whichreferstoavocabularyoftermsfordescribingtheimage. Notehowever,thatforgeneralXMLthereisnosemanticmodelthatdefinesthe interactionswithinXMLdocumentswithelementsand/orattributesfromavarietyof namespaces.Eachapplicationmustdefinehownamespacesinteractandwhat effectthenamespaceofanelementhasontheelement'sancestors,siblings,and descendants. SeeTAGissuesmixedUIXMLNamespace33(concerningthemeaningofa documentcomposedofcontentinmultiplenamespaces),xmlFunctions34 (concerningoneapproachformanagingXMLtransformationandcomposability), andRDFinXHTML35(concerningtheinterpretationofRDFwhenembeddedinan
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits 33/52

09/10/12

Architecture of the World Wide Web, Volume One

XHTMLdocument).

4.3.SeparationofContent,Presentation,andInteraction
TheWebisaheterogeneousenvironmentwhereawidevarietyofagentsprovide accesstocontenttouserswithawidevarietyofcapabilities.Itisgoodpracticefor authorstocreatecontentthatcanreachthewidestpossibleaudience,including userswithgraphicaldesktopcomputers,handhelddevicesandmobilephones, userswithdisabilitieswhomayrequirespeechsynthesizers,anddevicesnotyet imagined.Furthermore,authorscannotpredictinsomecaseshowanagentwill displayorprocesstheircontent.Experienceshowsthattheseparationofcontent, presentation,andinteractionpromotesthereuseanddeviceindependenceof contentthisfollowsfromtheprincipleoforthogonalspecifications(5.1). Thisseparationalsofacilitatesreuseofauthoredsourcecontentacrossmultiple deliverycontexts.Sometimes,functionaluserexperiencessuitedtoanydelivery contextcanbegeneratedbyusinganadaptationprocessappliedtoa representationthatdoesnotdependontheaccessmechanism.Formore informationaboutprinciplesofdeviceindependence,see[DIPRINCIPLES].

Goodpractice:Separationofcontent,presentation,interaction AspecificationSHOULDallowauthorstoseparatecontentfromboth presentationandinteractionconcerns. Notethatwhencontent,presentation,andinteractionareseparatedbydesign, agentsneedtorecombinethem.Thereisarecombinationspectrum,with"client doesall"atoneendand"serverdoesall"attheother. Thereareadvantagestoeachapproach.Forinstancewhenaclient(suchasa mobilephone)communicatesdevicecapabilitiestotheserver(forexample,using CC/PP),theservercantailorthedeliveredcontenttofitthatclient.Theservercan, forexample,enablefasterdownloadsbyadjustinglinkstorefertolowerresolution images,smallervideoornovideoatall.Similarly,ifthecontenthasbeenauthored withmultiplebranches,theservercanremoveunusedbranchesbeforedelivery.In addition,bytailoringthecontenttomatchthecharacteristicsofatargetclient,the servercanhelpreduceclientsidecomputation.However,specializingcontentin thismannerreducescachingefficiency. Ontheotherhand,designingcontentthatthatcanberecombinedontheclientalso tendstomakethatcontentapplicabletoawiderrangeofdevices.Thisdesignalso improvescachingefficiencyandoffersusersmorepresentationoptions.Media dependentstylesheetscanbeusedtotailorthecontentontheclientsideto particulargroupsoftargetdevices.Fortextualcontentwitharegularandrepeating structure,thecombinedsizeofthetextcontentplusthestylesheetistypicallyless thanthatoffullyrecombinedcontentthesavingsimprovefurtherifthestylesheet isreusedbyotherpages. Inpracticeacombinationofbothapproachesisoftenused.Thedesigndecision aboutwhereonthisspectrumanapplicationshouldbeplaceddependsonthe powerontheclient,thepowerandtheloadontheserver,andthebandwidthofthe
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits

mediumthatconnectsthem.Ifthenumberofpossibleclientsisunbounded,the

34/52

09/10/12

Architecture of the World Wide Web, Volume One

mediumthatconnectsthem.Ifthenumberofpossibleclientsisunbounded,the applicationwillscalebetterifmorecomputationispushedtotheclient. Ofcourse,itmaynotbedesirabletoreachthewidestpossibleaudience. Designersshouldconsiderappropriatetechnologies,suchasencryptionand accesscontrol(3.5.2),forlimitingtheaudience. Somedataformatsaredesignedtodescribepresentation(includingSVGandXSL FormattingObjects).Dataformatssuchasthesedemonstratethatonecanonly separatecontentfrompresentation(orinteraction)sofaratsomepointitbecomes necessarytotalkaboutpresentation.Pertheprincipleoforthogonalspecifications (5.1)thesedataformatsshouldonlyaddresspresentationissues. SeetheTAGissuesformattingProperties19(concerninginteroperabilityinthe caseofformattingpropertiesandnames)andcontentPresentation26(concerning theseparationofsemanticandpresentationalmarkup).

4.4.Hypertext
AdefiningcharacteristicoftheWebisthatitallowsembeddedreferencestoother resourcesviaURIs.ThesimplicityofcreatinghypertextlinksusingabsoluteURIs (< ah r e f = " h t t p : / / w w w . e x a m p l e . c o m / f o o " > )andrelativeURIreferences(< a h r e f = " f o o " > and< ah r e f = " f o o # a n c h o r " > )ispartly(perhapslargely)responsible forthesuccessofthehypertextWebasweknowittoday. Whenarepresentationofoneresourcecontainsareferencetoanotherresource, expressedwithaURIidentifyingthatotherresource,thisconstitutesalinkbetween thetworesources.Additionalmetadatamayalsoformpartofthelink(see [XLink10],forexample).Note:Inthisdocument,theterm"link"generallymeans "relationship",not"physicalconnection".

Goodpractice:Linkidentification AspecificationSHOULDprovidewaystoidentifylinkstoother resources,includingtosecondaryresources(viafragmentidentifiers). FormatsthatallowcontentauthorstouseURIsinsteadoflocalidentifierspromote thenetworkeffect:thevalueoftheseformatsgrowswiththesizeofthedeployed Web.

Goodpractice:Weblinking AspecificationSHOULDallowWebwidelinking,notjustinternal documentlinking.

Goodpractice:GenericURIs
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits 35/52

09/10/12

Architecture of the World Wide Web, Volume One

AspecificationSHOULDallowcontentauthorstouseURIswithout constrainingthemtoalimitedsetofURIschemes. WhatagentsdowithahypertextlinkisnotconstrainedbyWebarchitectureand maydependonapplicationcontext.Usersofhypertextlinksexpecttobeableto navigateamongrepresentationsbyfollowinglinks.

Goodpractice:Hypertextlinks AdataformatSHOULDincorporatehypertextlinksifhypertextisthe expecteduserinterfaceparadigm. Dataformatsthatdonotallowcontentauthorstocreatehypertextlinksleadtothe creationof"terminalnodes"ontheWeb. 4.4.1.URIreferences LinksarecommonlyexpressedusingURIreferences(definedinsection4.2of [URI]),whichmaybecombinedwithabaseURItoyieldausableURI.Section5.1 of[URI]explainsdifferentwaystoestablishabaseURIforaresourceand establishesaprecedenceamongthem.Forinstance,thebaseURImaybeaURI fortheresource,orspecifiedinarepresentation(seetheb a s e elementsprovided byHTMLandXML,andtheHTTP'ContentLocation'header).Seealsothesection onlinksinXML(4.5.2). AgentsresolveaURIreferencebeforeusingtheresultingURItointeractwith anotheragent.URIreferenceshelpincontentmanagementbyallowingcontent authorstodesignarepresentationlocally,i.e.,withoutconcernforwhichglobal identifiermaylaterbeusedtorefertotheassociatedresource.

4.5.XMLBasedDataFormats
ManydataformatsareXMLbased,thatistosaytheyconformtothesyntaxrules definedintheXMLspecification[XML10]or[XML11].Thissectiondiscusses issuesthatarespecifictosuchformats.Anyoneseekingguidanceinthisareais urgedtoconsultthe"GuidelinesFortheUseofXMLinIETFProtocols"[IETFXML], whichcontainsathoroughdiscussionoftheconsiderationsthatgovernwhetheror notXMLoughttobeused,aswellasspecificguidelinesonhowitoughttobe used.WhileitisdirectedatInternetapplicationswithspecificreferenceto protocols,thediscussionisgenerallyapplicabletoWebscenariosaswell. Thediscussionhereshouldbeseenasancillarytothecontentof[IETFXML].Refer alsoto"XMLAccessibilityGuidelines"[XAG]forhelpdesigningXMLformatsthat lowerbarrierstoWebaccessibilityforpeoplewithdisabilities. 4.5.1.WhentouseanXMLbasedformat XMLdefinestextualdataformatsthatarenaturallysuitedtodescribingdataobjects whicharehierarchicalandprocessedinachosensequence.Itiswidely,butnot
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits

universally,applicablefordataformatsanaudioorvideoformat,forexample,is

36/52

09/10/12

Architecture of the World Wide Web, Volume One

universally,applicablefordataformatsanaudioorvideoformat,forexample,is unlikelytobewellsuitedtoexpressioninXML.Designconstraintsthatwould suggesttheuseofXMLinclude: 1. Requirementforahierarchicalstructure. 2. Needforawiderangeoftoolsonavarietyofplatforms. 3. Needfordatathatcanoutlivetheapplicationsthatcurrentlyprocessit. 4. Abilitytosupportinternationalizationinaselfdescribingwaythatmakes confusionovercodingoptionsunlikely. 5. Earlydetectionofencodingerrorswithnorequirementto"workaround"such errors. 6. Ahighproportionofhumanreadabletextualcontent. 7. PotentialcompositionofthedataformatwithotherXMLencodedformats. 8. Desirefordataeasilyparsedbybothhumansandmachines. 9. Desireforvocabulariesthatcanbeinventedinadistributedmannerand combinedflexibly. 4.5.2.LinksinXML SophisticatedlinkingmechanismshavebeeninventedforXMLformats.XPointer allowslinkstoaddresscontentthatdoesnothaveanexplicit,namedanchor. [XLink]isanappropriatespecificationforrepresentinglinksinhypertext(4.4)XML applications.XLinkallowslinkstohavemultipleendsandtobeexpressedeither inlineorin"linkbases"storedexternaltoanyoralloftheresourcesidentifiedby thelinksitcontains. DesignersofXMLbasedformatsmayconsiderusingXLinkand,fordefining fragmentidentifiersyntax,usingtheXPointerframeworkandXPointerelement() Schemes. XLinkisnottheonlylinkingdesignthathasbeenproposedforXML,norisit universallyacceptedasagooddesign.SeealsoTAGissuexlinkScope23. 4.5.3.XMLnamespaces ThepurposeofanXMLnamespace(definedin[XMLNS])istoallowthe deploymentofXMLvocabularies(inwhichelementandattributenamesare defined)inaglobalenvironmentandtoreducetheriskofnamecollisionsina givendocumentwhenvocabulariesarecombined.Forexample,theMathMLand SVGspecificationsbothdefinethes e t element.AlthoughXMLdatafromdifferent formatssuchasMathMLandSVGcanbecombinedinasingledocument,inthis casetherecouldbeambiguityaboutwhichs e t elementwasintended.XML namespacesreducetheriskofnamecollisionsbytakingadvantageofexisting systemsforallocatinggloballyscopednames:theURIsystem(seealsothesection onURIallocation(2.2.2)).WhenusingXMLnamespaces,eachlocalnameinan XMLvocabularyispairedwithaURI(calledthenamespaceURI)todistinguishthe localnamefromlocalnamesinothervocabularies. TheuseofURIsconfersadditionalbenefits.First,eachURI/localnamepaircanbe mappedtoanotherURI,groundingthetermsofthevocabularyintheWeb.These termsmaybeimportantresourcesandthusitisappropriatetobeabletoassociate URIswiththem. [RDFXML]usessimpleconcatenationofthenamespaceURIandthelocalnameto
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits

createaURIfortheidentifiedterm.Othermappingsarelikelytobemoresuitable

37/52

09/10/12

Architecture of the World Wide Web, Volume One

createaURIfortheidentifiedterm.Othermappingsarelikelytobemoresuitable forhierarchicalnamespacesseetherelatedTAGissueabstractComponentRefs 37. DesignersofXMLbaseddataformatswhodeclarenamespacesthusmakeit possibletoreusethosedataformatsandcombinetheminnovelwaysnotyet imagined.Failuretodeclarenamespacesmakessuchreusemoredifficult,even impracticalinsomecases.

Goodpractice:Namespaceadoption AspecificationthatestablishesanXMLvocabularySHOULDplaceall elementnamesandglobalattributenamesinanamespace. Attributesarealwaysscopedbytheelementonwhichtheyappear.Anattributethat is"global,"thatis,onethatmightmeaningfullyappearonelementsofmanytypes, includingelementsinothernamespaces,shouldbeexplicitlyplacedina namespace.Localattributes,onesassociatedwithonlyaparticularelementtype, neednotbeincludedinanamespacesincetheirmeaningwillalwaysbeclearfrom thecontextprovidedbythatelement. Thet y p e attributefromtheW3CXMLSchemaInstancenamespace "http://www.w3.org/2001/XMLSchemainstance"([XMLSCHEMA],section4.3.2)is anexampleofaglobalattribute.Itcanbeusedbyauthorsofanyvocabularyto makeanassertionininstancedataaboutthetypeoftheelementonwhichit appears.Asaglobalattribute,itmustalwaysbequalified.Thef r a m e attributeonan HTMLtableisanexampleofalocalattribute.Thereisnovalueinplacingthat attributeinanamespacesincetheattributeisunlikelytobeusefulonanelement otherthananHTMLtable. ApplicationsthatrelyonDTDprocessingmustimposeadditionalconstraintsonthe useofnamespaces.DTDsperformvalidationbasedonthelexicalformofthe elementandattributenamesinthedocument.Thismakesprefixessyntactically significantinwaysthatarenotanticipatedby[XMLNS]. 4.5.4.Namespacedocuments

Story Nadiareceivesrepresentationdatafrom"weather.example.com"inan unfamiliardataformat.SheknowsenoughaboutXMLtorecognize whichXMLnamespacetheelementsbelongto.Sincethenamespaceis identifiedbytheURI"http://weather.example.com/2003/format",sheasks herbrowsertoretrievearepresentationoftheidentifiedresource.She getsbacksomeusefuldatathatallowshertolearnmoreaboutthedata format.Nadia'sbrowsermayalsobeabletoperformsomeoperations automatically(i.e.,unattendedbyahumanoverseer)givendatathathas beenoptimizedforsoftwareagents.Forexample,herbrowsermight,on Nadia'sbehalf,downloadadditionalagentstoprocessandrenderthe
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits

format.

38/52

09/10/12

Architecture of the World Wide Web, Volume One

format. AnotherbenefitofusingURIstobuildXMLnamespacesisthatthenamespaceURI canbeusedtoidentifyaninformationresourcethatcontainsusefulinformation, machineusableand/orhumanusable,abouttermsinthenamespace.Thistypeof informationresourceiscalledanamespacedocument.WhenanamespaceURI ownerprovidesanamespacedocument,itisauthoritativeforthenamespace. Therearemanyreasonstoprovideanamespacedocument.Apersonmightwant to: understandthepurposeofthenamespace, learnhowtousethemarkupvocabularyinthenamespace, findoutwhocontrolsitandassociatedpolicies, requestauthoritytoaccessschemasorcollateralmaterialaboutit,or reportabugorsituationthatcouldbeconsideredanerrorinsomecollateral material. Aprocessormightwantto: retrieveaschema,forvalidation, retrieveastylesheet,forpresentation,or retrieveontologies,formakinginferences. Ingeneral,thereisnoestablishedbestpracticeforcreatingrepresentationsofa namespacedocumentapplicationexpectationswillinfluencewhatdataformator formatsareused.Applicationexpectationswillalsoinfluencewhetherrelevant informationappearsdirectlyinarepresentationorisreferencedfromit.

Goodpractice:Namespacedocuments TheownerofanXMLnamespacenameSHOULDmakeavailable materialintendedforpeopletoreadandmaterialoptimizedforsoftware agentsinordertomeettheneedsofthosewhowillusethenamespace vocabulary. Forexample,thefollowingareexamplesofdataformatsfornamespace documents:[OWL10],[RDDL],[XMLSCHEMA],and[XHTML11].Eachofthese formatsmeetsdifferentrequirementsdescribedaboveforsatisfyingtheneedsofan agentthatwantsmoreinformationaboutthenamespace.Note,however,issues relatedtofragmentidentifiersandcontentnegotiation(3.2.2)ifcontentnegotiation isused. SeeTAGissuesnamespaceDocument8(concerningdesiredcharacteristicsof namespacedocuments)andabstractComponentRefs37(concerningtheuseof fragmentidentifierswithnamespacenamestoidentifyabstractcomponents). 4.5.5.QNamesinXML Section3of"NamespacesinXML"[XMLNS]providesasyntacticconstructknown asaQNameforthecompactexpressionofqualifiednamesinXMLdocuments.A
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits 39/52

09/10/12

Architecture of the World Wide Web, Volume One

qualifiednameisapairconsistingofaURI,whichnamesanamespace,anda localnameplacedwithinthatnamespace."NamespacesinXML"providesforthe useofQNamesasnamesforXMLelementsandattributes. Otherspecifications,startingwith[XSLT10],haveemployedtheideaofusing QNamesincontextsotherthanelementandattributenames,forexamplein attributevaluesandinelementcontent.However,generalXMLprocessorscannot reliablyrecognizeQNamesassuchwhentheyareusedinattributevaluesandin elementcontentforexample,thesyntaxofQNamesoverlapswiththatofURIs. ExperiencehasalsorevealedotherlimitationstoQNames,suchaslosing namespacebindingsafterXMLcanonicalization.

Constraint:QNamesIndistinguishablefromURIs DonotallowbothQNamesandURIsinattributevaluesorelement contentwheretheyareindistinguishable. Formoreinformation,seetheTAGfinding"UsingQNamesasIdentifiersin Content". BecauseQNamesarecompact,somespecificationdesignershaveadoptedthe samesyntaxasameansofidentifyingresources.Thoughconvenientasa shorthandnotation,thisusagehasacost.Thereisnosingle,acceptedwayto convertaQNameintoaURIorviceversa.AlthoughQNamesareconvenient,they donotreplacetheURIastheidentificationsystemoftheWeb.TheuseofQNames toidentifyWebresourceswithoutprovidingamappingtoURIsisinconsistentwith Webarchitecture.

Goodpractice:QNameMapping AspecificationinwhichQNamesserveasresourceidentifiersMUST provideamappingtoURIs. SeeXMLnamespaces(4.5.3)forexamplesofsomemappingstrategies. SeealsoTAGissuesrdfmsQnameUriMapping6(concerningthemappingof QNamestoURIs),qnameAsId18(concerningtheuseofQNamesasidentifiersin XMLcontent),andabstractComponentRefs37(concerningtheuseoffragment identifierswithnamespacenamestoidentifyabstractcomponents). 4.5.6.XMLIDsemantics ConsiderthefollowingfragmentofXML:< s e c t i o nn a m e = " f o o " > .Doesthes e c t i o n elementhavewhattheXMLRecommendationreferstoastheIDf o o (i.e.,"foo" mustnotappearinthesurroundingXMLdocumentmorethanonce)?Onecannot answerthisquestionbyexaminingtheelementanditsattributesalone.InXML,the qualityof"beinganID"isassociatedwiththetypeofanattribute,notitsname. FindingtheIDsinadocumentrequiresadditionalprocessing.
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits 40/52

09/10/12

Architecture of the World Wide Web, Volume One

1. ProcessingthedocumentwithaprocessorthatrecognizesDTDattributelist declarations(intheexternalorinternalsubset)mightrevealadeclarationthat identifiesthen a m e attributeasanID.Note:Thisprocessingisnotnecessarily partofvalidation.Anonvalidating,DTDawareprocessorcanrecognizeIDs. 2. ProcessingthedocumentwithaW3CXMLschemamightrevealanelement declarationthatidentifiesthen a m e attributeasanW3CXMLSchemaI D . 3. Inpractice,processingthedocumentwithanotherschemalanguage,suchas RELAXNG[RELAXNG],mightrevealtheattributesdeclaredtobeofIDinthe XMLSchemasense.ManymodernspecificationsbeginprocessingXMLat theInfoset[INFOSET]levelanddonotspecifynormativelyhowanInfosetis constructed.Forthosespecifications,anyprocessthatestablishestheIDtype intheInfoset(andPostSchemaValidationInfoset(PSVI)definedin [XMLSCHEMA])mayusefullyidentifytheattributesoftypeID. 4. Inpractice,applicationsmayhaveindependentmeans(suchasthose definedintheXPointerspecification,[XPTRFR]section3.2)oflocating identifiersinsideadocument. Tofurthercomplicatematters,DTDsestablishtheIDtypeintheInfosetwhereas W3CXMLSchemaproducesaPSVIbutdoesnotmodifytheoriginalInfoset.This leavesopenthepossibilitythataprocessormightonlylookintheInfosetand consequentlywouldfailtorecognizeschemaassignedIDs. SeetheTAGissuexmlIDSemantics32foradditionalbackgroundinformationand [XMLID]forasolutionunderdevelopment. 4.5.7.MediatypesforXML RFC3023definestheInternetmediatypes"application/xml"and"text/xml",and describesaconventionwherebyXMLbaseddataformatsuseInternetmediatypes witha"+xml"suffix,forexample"image/svg+xml". Therearetwoproblemsassociatedwiththetextmediatypes:First,fordata identifiedas"text/*",Webintermediariesareallowedto"transcode",i.e.,convert onecharacterencodingtoanother.Transcodingmaymaketheselfdescription falseormaycausethedocumenttobenotwellformed.

Goodpractice:XMLand"text/*" Ingeneral,arepresentationproviderSHOULDNOTassignInternet mediatypesbeginningwith"text/"toXMLrepresentations. Second,representationswhoseInternetmediatypesbeginwith"text/"arerequired, unlessthec h a r s e t parameterisspecified,tobeconsideredtobeencodedinUS ASCII.SincethesyntaxofXMLisdesignedtomakedocumentsselfdescribing,it isgoodpracticetoomitthec h a r s e t parameter,andsinceXMLisveryoftennot encodedinUSASCII,theuseof"text/"Internetmediatypeseffectivelyprecludes thisgoodpractice.

Goodpractice:XMLandcharacterencodings
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits 41/52

09/10/12

Architecture of the World Wide Web, Volume One

Ingeneral,arepresentationproviderSHOULDNOTspecifythe characterencodingforXMLdatainprotocolheaderssincethedatais selfdescribing. 4.5.8.FragmentidentifiersinXML Thesectiononmediatypesandfragmentidentifiersemantics(3.2.1)discusses theinterpretationoffragmentidentifiers.DesignersofanXMLbaseddataformat specificationshoulddefinethesemanticsoffragmentidentifiersinthatformat.The XPointerFramework[XPTRFR]providesaninteroperablestartingpoint. Whenthemediatypeassignedtorepresentationdatais"application/xml",thereare nosemanticsdefinedforfragmentidentifiers,andauthorsshouldnotmakeuseof fragmentidentifiersinsuchdata.Thesameistrueiftheassignedmediatypehas thesuffix"+xml"(definedin"XMLMediaTypes"[RFC3023]),andthedataformat specificationdoesnotspecifyfragmentidentifiersemantics.Inshort,justknowing thatcontentisXMLdoesnotprovideinformationaboutfragmentidentifier semantics. Manypeopleassumethatthefragmentidentifier# a b c ,whenreferringtoXMLdata, identifiestheelementinthedocumentwiththeID"abc".However,thereisno normativesupportforthisassumption.ArevisionofRFC3023isexpectedto addressthis. SeeTAGissuefragmentInXML28.

4.6.FutureDirectionsforDataFormats
Dataformatsenablethecreationofnewapplicationstomakeuseoftheinformation spaceinfrastructure.TheSemanticWebisonesuchapplication,builtontopof RDF[RDFXML].ThisdocumentdoesnotdiscusstheSemanticWebindetailthe TAGexpectsthatfuturevolumesofthisdocumentwill.SeetherelatedTAGissue httpRange14.

5.GeneralArchitecturePrinciples
AnumberofgeneralarchitectureprinciplesapplytoallthreebasesofWeb architecture.

5.1.OrthogonalSpecifications
Identification,interaction,andrepresentationareorthogonalconcepts,meaning thattechnologiesusedforidentification,interaction,andrepresentationmayevolve independently.Forinstance: ResourcesareidentifiedwithURIs.URIscanbepublishedwithoutbuilding anyrepresentationsoftheresourceordeterminingwhetherany representationsareavailable. AgenericURIsyntaxallowsagentstofunctioninmanycaseswithout knowingspecificsofURIschemes. Inmanycasesonemaychangetherepresentationofaresourcewithout disruptingreferencestotheresource(forexample,byusingcontent
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits 42/52

09/10/12

Architecture of the World Wide Web, Volume One

negotiation). Whentwospecificationsareorthogonal,onemaychangeonewithoutrequiring changestotheother,evenifonehasdependenciesontheother.Forexample, althoughtheHTTPspecificationdependsontheURIspecification,thetwomay evolveindependently.Thisorthogonalityincreasestheflexibilityandrobustnessof theWeb.Forexample,onemayreferbyURItoanimagewithoutknowinganything abouttheformatchosentorepresenttheimage.Thishasfacilitatedtheintroduction ofimageformatssuchasPNGandSVGwithoutdisruptingexistingreferencesto imageresources.

Principle:Orthogonality Orthogonalabstractionsbenefitfromorthogonalspecifications. Experiencedemonstratesthatproblemsarisewhereorthogonalconceptsoccurin asinglespecification.Consider,forexample,theHTMLspecificationwhich includestheorthogonalxwwwformurlencodedspecification.Softwaredevelopers (forexample,of[CGI]applications)mighthaveaneasiertimefindingthe specificationifitwerepublishedseparatelyandthencitedfromtheHTTP,URI,and HTMLspecifications. Problemsalsoarisewhenspecificationsattempttomodifyorthogonalabstractions describedelsewhere.AnhistoricalversionoftheHTMLspecificationaddeda "R e f r e s h "valuetotheh t t p e q u i v attributeofthem e t a element.Itwasdefinedtobe equivalenttotheHTTPheaderofthesamename.TheauthorsoftheHTTP specificationultimatelydecidednottoprovidethisheaderandthatmadethetwo specificationsawkwardlyatoddswitheachother.TheW3CHTMLWorkingGroup eventuallyremovedthe"R e f r e s h "value. Aspecificationshouldclearlyindicatewhichfeaturesoverlapwiththosegoverned byanotherspecification.

5.2.Extensibility
TheinformationintheWebandthetechnologiesusedtorepresentthatinformation changeovertime.Extensibilityisthepropertyofatechnologythatpromotes evolutionwithoutsacrificinginteroperability.Someexamplesofsuccessful technologiesdesignedtoallowchangewhileminimizingdisruptioninclude: thefactthatURIschemesareorthogonallyspecified theuseofanopensetofInternetmediatypesinmailandHTTPtospecify documentinterpretation theseparationofthegenericXMLgrammarandtheopensetofXML namespacesforelementandattributenames extensibilitymodelsinCascadingStyleSheets(CSS),XSLT1.0,andSOAP useragentplugins. AnexampleofanunsuccessfulextensionmechanismisHTTPmandatory extensions[HTTPEXT].ThecommunityhassoughtmechanismstoextendHTTP, butapparentlythecostsofthemandatoryextensionproposal(notablyin
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits

complexity)outweighedthebenefitsandthushamperedadoption.

43/52

09/10/12

Architecture of the World Wide Web, Volume One

complexity)outweighedthebenefitsandthushamperedadoption. Belowwediscussthepropertyof"extensibility,"exhibitedbyURIs,somedata formats,andsomeprotocols(throughtheincorporationofnewmessages). Subsetlanguage:onelanguageisasubset(or"profile")ofasecondlanguageif anydocumentinthefirstlanguageisalsoavaliddocumentinthesecond languageandhasthesameinterpretationinthesecondlanguage. Extendedlanguage:Ifonelanguageisasubsetofanother,thelattersupersetis calledanextendedlanguagethedifferencebetweenthelanguagesiscalledthe extension.Clearly,extendingalanguageisbetterforinteroperabilitythancreating anincompatiblelanguage. Ideally,manyinstancesofasupersetlanguagecanbesafelyandusefully processedasthoughtheywereinthesubsetlanguage.Languagesthatcanevolve thisway,allowingapplicationstoprovidenewinformationwhennecessarywhile stillinteroperatingwithapplicationsthatonlyunderstandasubsetofthecurrent language,aresaidtobe"extensible."Languagedesignerscanfacilitate extensibilitybydefiningthedefaultbehaviorofunknownextensionsforexample, thattheybeignored(insomedefinedway)orshouldbeconsiderederrors. Forexample,fromearlyonintheWeb,HTMLagentsfollowedtheconventionof ignoringunknowntags.Thischoiceleftroomforinnovation(i.e.,nonstandard elements)andencouragedthedeploymentofHTML.However,interoperability problemsaroseaswell.Inthistypeofenvironment,thereisaninevitabletension betweeninteroperabilityintheshorttermandthedesireforextensibility. Experienceshowsthatdesignsthatstriketherightbalancebetweenallowing changeandpreservinginteroperabilityaremorelikelytothriveandarelesslikely todisrupttheWebcommunity.Orthogonalspecifications(5.1)helpreducetherisk ofdisruption. Forfurtherdiscussion,seethesectiononversioningandextensibility(4.2).See alsoTAGissuexmlProfiles29andHTMLDialects.

5.3.ErrorHandling
Errorsoccurinnetworkedinformationsystems.Anerrorconditioncanbewell characterized(e.g.,wellformednesserrorsinXMLor4xxclienterrorsinHTTP)or ariseunpredictably.Errorcorrectionmeansthatanagentrepairsaconditionso thatwithinthesystem,itisasthoughtheerrorneveroccurred.Oneexampleof errorcorrectioninvolvesdataretransmissioninresponsetoatemporarynetwork failure.Errorrecoverymeansthatanagentdoesnotrepairanerrorconditionbut continuesprocessingbyaddressingthefactthattheerrorhasoccurred. Agentsfrequentlycorrecterrorswithoutuserawareness,sparingusersthedetails ofcomplexnetworkcommunications.Ontheotherhand,itisimportantthatagents recoverfromerrorinawaythatisevidenttousers,sincetheagentsareactingon theirbehalf.

Principle:Errorrecovery

www.w3.org/TR/2004/RECwebarch20041215/#uribenefits

44/52

09/10/12

Architecture of the World Wide Web, Volume One

Agentsthatrecoverfromerrorbymakingachoicewithouttheuser's consentarenotactingontheuser'sbehalf. Anagentisnotrequiredtointerrupttheuser(e.g.,bypoppingupaconfirmation box)toobtainconsent.Theusermayindicateconsentthroughpreselected configurationoptions,modes,orselectableuserinterfacetoggles,withappropriate reportingtotheuserwhentheagentdetectsanerror.Agentdevelopersshouldnot ignoreusabilityissueswhendesigningerrorrecoverybehavior. Topromoteinteroperability,specificationdesignersshouldidentifypredictable errorconditions.Experiencehasledtothefollowingobservationsabouterror handlingapproaches. Protocoldesignersshouldprovideenoughinformationaboutanerror conditionsothatanagentcanaddresstheerrorcondition.Forinstance,an HTTP404statuscode(notfound)isusefulbecauseitallowsuseragentsto presentrelevantinformationtousers,enablingthemtocontactthe representationproviderincaseofproblems. Experiencewiththecostofbuildingauseragenttohandlethediverseforms ofillformedHTMLcontentconvincedthedesignersoftheXMLspecification torequirethatagentsfailuponencounteringillformedcontent.Because usersareunlikelytotoleratesuchfailures,thisdesignchoicehaspressured allpartiesintorespectingXML'sconstraints,tothebenefitofall. Anagentthatencountersunrecognizedcontentmayhandleitinanumberof ways,includingbyconsideringitanerrorseealsothesectionon extensibilityandversioning(4.2). Errorbehaviorthatisappropriateforapersonmaynotbeappropriatefor software.Peoplearecapableofexercisingjudgementinwaysthatsoftware applicationsgenerallycannot.Aninformalerrorresponsemaysufficefora personbutnotforaprocessor. SeetheTAGissuecontentTypeOverride24,whichconcernsthesourceof authoritativemetadata.

5.4.ProtocolbasedInteroperability
TheWebfollowsInternettraditioninthatitsimportantinterfacesaredefinedin termsofprotocols,byspecifyingthesyntax,semantics,andsequencingconstraints ofthemessagesinterchanged.Protocolsdesignedtoberesilientinthefaceof widelyvaryingenvironmentshavehelpedtheWebscaleandhavefacilitated communicationacrossmultipletrustboundaries.Traditionalapplication programminginterfaces(APIs)donotalwaystaketheseconstraintsintoaccount, norshouldtheyberequiredto.Oneeffectofprotocolbaseddesignisthatthe technologysharedamongagentsoftenlastslongerthantheagentsthemselves. ItiscommonforprogrammersworkingwiththeWebtowritecodethatgenerates andparsesthesemessagesdirectly.Itislesscommon,butnotunusual,forend userstohavedirectexposuretothesemessages.Itisoftendesirabletoprovide userswithaccesstoformatandprotocoldetails:allowingthemtoviewsource, wherebytheymaygainexpertiseintheworkingsoftheunderlyingsystem.

6.Glossary
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits 45/52

09/10/12

Architecture of the World Wide Web, Volume One

Contentnegotiation Thepracticeofprovidingmultiplerepresentationsavailableviathesame URI.Whichrepresentationisserveddependsonnegotiationbetweenthe requestingagentandtheagentservingtherepresentations. DereferenceaURI AccessarepresentationoftheresourceidentifiedbytheURI. Errorcorrection Anagentrepairsanerrorsothatwithinthesystem,itisasthoughtheerror neveroccurred. Errorrecovery Anagentinvokesexceptionalbehaviorbecauseitdoesnotcorrecttheerror. Extendedlanguage Ifonelanguageisasubsetofanother,thelatteriscalledanextended language. Fragmentidentifier ThepartofaURIthatallowsidentificationofasecondaryresource. Informationresource Aresourcewhichhasthepropertythatallofitsessentialcharacteristicscan beconveyedinamessage. Link Arelationshipbetweentworesourceswhenoneresource(representation) referstotheotherresourcebymeansofaURI. Message Aunitofcommunicationbetweenagents. Namespacedocument AninformationresourceidentifiedbyanXMLNamespaceURIthatcontains usefulinformation,machineusableand/orhumanusable,abouttermsina particularXMLnamespace.Itisuseful,thoughnotmanditory,thattheURI employedasanamespacenameidentifiesanamespacedocument. Representation Datathatencodesinformationaboutresourcestate. Resource AnythingthatmightbeidentifiedbyaURI. Safeinteraction Interactionwitharesourcewhereanagentdoesnotincuranyobligation beyondtheinteraction. Secondaryresource Aresourcerelatedtoanotherresourcethroughtheprimaryresourcewith additionalidentifyinginformation(thefragmentidentifier). Subsetlanguage Onelanguageisasubsetofasecondlanguageifanydocumentinthefirst languageisalsoavaliddocumentinthesecondlanguageandhasthesame interpretationinthesecondlanguage. URI AcronymforUniformResourceIdentifier. URIaliases TwoormoredifferentURIsthatthatidentifythesameresource. URIcollision TheuseofthesameURItorefertomorethanoneresourceinthecontextof Webprotocolsandformats. URIownership ArelationshipbetweenaURIandasocialentity,suchasaperson, organization,orspecification. URIpersistence
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits 46/52

09/10/12

Architecture of the World Wide Web, Volume One

ThesocialexpectationthatonceaURIidentifiesaparticularresource,it shouldcontinueindefinitelytorefertothatresource. URIreference AnoperationalshorthandforaURI. UniformResourceIdentifier(URI) AglobalidentifierinthecontextoftheWorldWideWeb. Unsafeinteraction Interactionwitharesourcethatisnotsafeinteraction. Useragent OnetypeofWebagentapieceofsoftwareactingonbehalfofaperson. WWW AcronymforWorldWideWeb. Web ShortenedformofWorldWideWeb. Webagent Apersonorapieceofsoftwareactingontheinformationspaceonbehalfofa person,entity,orprocess. WorldWideWeb AninformationspaceinwhichitemsofinterestareidentifiedbyUniform ResourceIdentifiers. XMLbasedformat OnethatconformstothesyntaxrulesdefinedintheXMLspecification.

7.References
CGI CommonGatewayInterface/1.1Specification.Availableat http://hoohoo.ncsa.uiuc.edu/cgi/interface.html. CHIPS CommonHTTPImplementationProblems,O.Threaux,January2003.This W3CTeamSubmissionisavailableathttp://www.w3.org/TR/chips/. CUAP CommonUserAgentProblems,K.Dubost,January2003.ThisW3CTeam Submissionisavailableathttp://www.w3.org/TR/cuap. Cool CoolURIsdon'tchangeT.BernersLee,W3C,1998Availableat http://www.w3.org/Provider/Style/URI.Notethatthetitleissomewhat misleading.ItisnottheURIsthatchange,itiswhattheyidentify. Eng90 KnowledgeDomainInteroperabilityandanOpenHyperdocumentSystem,D. C.Engelbart,June1990. HTTPEXT MandatoryExtensionsinHTTP,H.FrystykNielsen,P.Leach,S.Lawrence, 20January1998.ThisexpiredInternetDraftisavailableat http://www.w3.org/Protocols/HTTP/ietfhttpext/draftfrystykhttpmandatory. IANASchemes IANA'sonlineregistryofURISchemesisavailableat http://www.iana.org/assignments/urischemes. IETFXML IETFGuidelinesForTheUseofXMLinIETFProtocols,S.Hollenbeck,M. Rose,L.Masinter,eds.,2November2002.ThisInternetDraftisavailableat http://www.imc.org/ietfxmluse/xmlguidelines07.txt.Ifthisdocumentisno longeravailable,refertotheietfxmlusemailinglist. INFOSET
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits 47/52

09/10/12

Architecture of the World Wide Web, Volume One

XMLInformationSet(SecondEdition),R.Tobin,J.Cowan,Editors,W3C Recommendation,04February2004,http://www.w3.org/TR/2004/RECxml infoset20040204.Latestversionavailableathttp://www.w3.org/TR/xml infoset. IRI IETFInternationalizedResourceIdentifiers(IRIs),M.Drst,M.Suignard, Eds.,November2004.Inan8December2004announcement,theIESG approveddraftduerstiri11asaProposedStandardoftheIETF.References totheIRIspecificationinVolumeOneofArchitectureoftheWorldWideWeb aretothatProposedStandard.OncetheIETFissuesaRequestFor Comments(RFC)numberforthespecification,thisW3CRecommendation maybeupdatedtorefertothatRFC.Seealsothelatestinformationaboutthe IRIspecification. MEDIATYPEREG IANA'sonlineregistryofInternetMediaTypesisavailableat http://www.iana.org/assignments/mediatypes/index.html. OWL10 OWLWebOntologyLanguageReference,M.Dean,G.Schreiber,Editors, W3CRecommendation,10February2004,http://www.w3.org/TR/2004/REC owlref20040210/.Latestversionavailableathttp://www.w3.org/TR/owlref/. P3P10 ThePlatformforPrivacyPreferences1.0(P3P1.0)Specification,M. Marchiori,Editor,W3CRecommendation,16April2002, http://www.w3.org/TR/2002/RECP3P20020416/.Latestversionavailableat http://www.w3.org/TR/P3P/. RDDL ResourceDirectoryDescriptionLanguage(RDDL),J.Borden,T.Bray,eds.,1 June2003.Thisdocumentisavailableat http://www.tbray.org/tag/rddl/rddl3.html. RDFXML RDF/XMLSyntaxSpecification(Revised),D.Beckett,Editor,W3C Recommendation,10February2004,http://www.w3.org/TR/2004/RECrdf syntaxgrammar20040210/.Latestversionavailableat http://www.w3.org/TR/rdfsyntaxgrammar. RELAXNG TheRELAXNGschemalanguageproject. REST RepresentationalStateTransfer(REST),Chapter5of"ArchitecturalStyles andtheDesignofNetworkbasedSoftwareArchitectures",DoctoralThesisof R.T.Fielding,2000.Designersofprotocolspecificationsinparticularshould investtimeinunderstandingtheRESTmodelandtherelevanceofits principlestoagivendesign.Theseprinciplesincludestatelessness,clear assignmentofrolestoparties,uniformaddressspace,andalimited,uniform setofverbs.Availableat http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm. RFC2045 IETFRFC2045:MultipurposeInternetMailExtensions(MIME)PartOne: FormatofInternetMessageBodies,N.Freed,N.Borenstein,November 1996.Availableathttp://www.ietf.org/rfc/rfc2045.txt. RFC2046 IETFRFC2046:MultipurposeInternetMailExtensions(MIME)PartTwo: MediaTypes,N.Freed,N.Borenstein,November1996.Availableat http://www.ietf.org/rfc/rfc2046.txt. RFC2119
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits 48/52

09/10/12

Architecture of the World Wide Web, Volume One

IETFRFC2119:KeywordsforuseinRFCstoIndicateRequirementLevels, S.Bradner,March1997.Availableathttp://www.ietf.org/rfc/rfc2119.txt. RFC2141 IETFRFC2141:URNSyntax,R.Moats,May1997.Availableat http://www.ietf.org/rfc/rfc2141.txt. RFC2326 IETFRFC2326:RealTimeStreamingProtocol(RTSP),H.Schulzrinne,A. Rao,R.Lanphier,April1998.Availableat:http://www.ietf.org/rfc/rfc2326.txt. RFC2397 IETFRFC2397:ThedataURLscheme,L.Masinter,August1998. Availableat:http://www.ietf.org/rfc/rfc2397.txt. RFC2616 IETFRFC2616:HypertextTransferProtocolHTTP/1.1,J.Gettys,J.Mogul, H.Frystyk,L.Masinter,P.Leach,T.BernersLee,June1999.Availableat http://www.ietf.org/rfc/rfc2616.txt. RFC2717 IETFRegistrationProceduresforURLSchemeNames,R.Petke,I.King, November1999.Availableathttp://www.ietf.org/rfc/rfc2717.txt. RFC2718 IETFRFC2718:GuidelinesfornewURLSchemes,L.Masinter,H. Alvestrand,D.Zigmond,R.Petke,November1999.Availableat: http://www.ietf.org/rfc/rfc2718.txt. RFC2818 IETFRFC2818:HTTPOverTLS,E.Rescorla,May2000.Availableat: http://www.ietf.org/rfc/rfc2818.txt. RFC3023 IETFRFC3023:XMLMediaTypes,M.Murata,S.St.Laurent,D.Kohn, January2001.Availableat:http://www.ietf.org/rfc/rfc3023.txt RFC3236 IETFRFC3236:The'application/xhtml+xml'MediaType,M.Baker,P.Stark, January2002.Availableat:http://www.ietf.org/rfc/rfc3236.txt RFC3261 IETFRFC3261:SIP:SessionInitiationProtocol,J.Rosenberg,H. Schulzrinne,G.Camarillo,et.al.,June2002.Availableat: http://www.ietf.org/rfc/rfc3261.txt RFC3920 IETFRFC3920:ExtensibleMessagingandPresenceProtocol(XMPP): Core,P.SaintAndre,Ed.,October2004.Availableat: http://www.ietf.org/rfc/rfc3920.txt RFC977 IETFRFC977:NetworkNewsTransferProtocol,B.Kantor,P.Lapsley, February1986.Availableathttp://www.ietf.org/rfc/rfc977.txt. SOAP12 SOAPVersion1.2Part1:MessagingFramework,J.Moreau,N.Mendelsohn, H.FrystykNielsen,et.al.,Editors,W3CRecommendation,24June2003, http://www.w3.org/TR/2003/RECsoap12part120030624/.Latestversion availableathttp://www.w3.org/TR/soap12part1/. SVG11 ScalableVectorGraphics(SVG)1.1Specification, ,J.Ferraiolo,D. Jackson,Editors,W3CRecommendation,14January2003, http://www.w3.org/TR/2003/RECSVG1120030114/.Latestversionavailable athttp://www.w3.org/TR/SVG11/. UNICODE TheUnicodeConsortium,TheUnicodeStandard,Version4,ISBN0321

www.w3.org/TR/2004/RECwebarch20041215/#uribenefits

49/52

09/10/12

Architecture of the World Wide Web, Volume One

185781,asupdatedfromtimetotimebythepublicationofnewversions.See http://www.unicode.org/unicode/standard/versionsforthelatestUnicode versionandadditionalinformationonversionsofthestandardandofthe UnicodeCharacterDatabase. URI IETFUniformResourceIdentifiers(URI):GenericSyntax,T.BernersLee,R. Fielding,L.Masinter,Eds.,September2004.Inan18October2004 announcement,theIESGapproveddraftfieldingurirfc2396bis07asaFull StandardoftheIETF.ReferencestotheURIspecificationinVolumeOneof ArchitectureoftheWorldWideWebaretothatFullStandard.OncetheIETF issuesaRequestForComments(RFC)numberforthespecification,this W3CRecommendationmaybeupdatedtorefertothatRFC.Seealsothe latestinformationabouttheURIspecification. UniqueDNS IABTechnicalCommentontheUniqueDNSRoot,B.Carpenter,27 September1999.Availableathttp://www.icann.org/correspondence/iabtech comment27sept99.htm. VOICEXML2 VoiceExtensibleMarkupLanguage(VoiceXML)Version2.0,B.Porter,A. Hunt,K.Rehor,et.al.,Editors,W3CRecommendation,16March2004, http://www.w3.org/TR/2004/RECvoicexml2020040316/.Latestversion availableathttp://www.w3.org/TR/voicexml20. XHTML11 XHTML1.1ModulebasedXHTML,S.McCarron,M.Altheim,Editors, W3CRecommendation,31May2001,http://www.w3.org/TR/2001/REC xhtml1120010531.Latestversionavailableat http://www.w3.org/TR/xhtml11/. XLink10 XMLLinkingLanguage(XLink)Version1.0,E.Maler,S.DeRose,D.Orchard, Editors,W3CRecommendation,27June2001, http://www.w3.org/TR/2001/RECxlink20010627/.Latestversionavailableat http://www.w3.org/TR/xlink/. XMLID xml:idVersion1.0,D.Veillard,J.Marsh,Editors,W3CWorkingDraft(workin progress),07April2004,http://www.w3.org/TR/2004/WDxmlid20040407. Latestversionavailableathttp://www.w3.org/TR/xmlid/. XML10 ExtensibleMarkupLanguage(XML)1.0(ThirdEdition),F.Yergeau,J.Paoli, C.M.SperbergMcQueen,et.al.,Editors,W3CRecommendation, 04February2004,http://www.w3.org/TR/2004/RECxml20040204.Latest versionavailableathttp://www.w3.org/TR/RECxml. XML11 ExtensibleMarkupLanguage(XML)1.1,J.Paoli,C.M.SperbergMcQueen, J.Cowan,et.al.,Editors,W3CRecommendation,04February2004, http://www.w3.org/TR/2004/RECxml1120040204/.Latestversionavailable athttp://www.w3.org/TR/xml11/. XMLNS NamespacesinXML1.1,R.Tobin,D.Hollander,A.Layman,et.al.,Editors, W3CRecommendation,04February2004,http://www.w3.org/TR/2004/REC xmlnames1120040204.Latestversionavailableat http://www.w3.org/TR/xmlnames11/. XMLSCHEMA XMLSchemaPart1:Structures,D.Beech,M.Maloney,H.S.Thompson,et. al.,Editors,W3CRecommendation,02May2001,
www.w3.org/TR/2004/RECwebarch20041215/#uribenefits 50/52

09/10/12

Architecture of the World Wide Web, Volume One

http://www.w3.org/TR/2001/RECxmlschema120010502/.Latestversion availableathttp://www.w3.org/TR/xmlschema1/. XPTRFR XPointerFramework,E.Maler,N.Walsh,P.Grosso,et.al.,Editors,W3C Recommendation,25March2003,http://www.w3.org/TR/2003/RECxptr framework20030325/.Latestversionavailableathttp://www.w3.org/TR/xptr framework/. XSLT10 XSLTransformations(XSLT)Version1.0,J.Clark,Editor,W3C Recommendation,16November1999,http://www.w3.org/TR/1999/RECxslt 19991116.Latestversionavailableathttp://www.w3.org/TR/xslt.

7.1.ArchitecturalSpecifications
ATAG10 AuthoringToolAccessibilityGuidelines1.0,C.McCathieNevile,I.Jacobs,J. Treviranus,et.al.,Editors,W3CRecommendation,03February2000, http://www.w3.org/TR/2000/RECATAG1020000203.Latestversion availableathttp://www.w3.org/TR/ATAG10. CHARMOD CharacterModelfortheWorldWideWeb1.0:Fundamentals,R.Ishida,M.J. Drst,M.Wolf,et.al.,Editors,W3CWorkingDraft(workinprogress), 25February2004,http://www.w3.org/TR/2004/WDcharmod20040225/. Latestversionavailableathttp://www.w3.org/TR/charmod/. DIPRINCIPLES DeviceIndependencePrinciples,R.Gimson,Editor,W3CNote, 01September2003,http://www.w3.org/TR/2003/NOTEdiprinc20030901/. Latestversionavailableathttp://www.w3.org/TR/diprinc/. EXTLANG WebArchitecture:ExtensibleLanguages,T.BernersLee,D.Connolly,10 February1998.ThisW3CNoteisavailableat http://www.w3.org/TR/1998/NOTEwebarchextlang19980210. Fielding PrincipledDesignoftheModernWebArchitecture,R.T.FieldingandR.N. Taylor,UCIrvine.InProceedingsofthe2000InternationalConferenceon SoftwareEngineering(ICSE2000),Limerick,Ireland,June2000,pp.407 416.Thisdocumentisavailableat http://www.ics.uci.edu/~fielding/pubs/webarch_icse2000.pdf. QA QAFramework:SpecificationGuidelines,D.HazalMassieux,L.Rosenthal, L.Henderson,et.al.,Editors,W3CWorkingDraft(workinprogress), 30August2004,http://www.w3.org/TR/2004/WDqaframespec20040830/. Latestversionavailableathttp://www.w3.org/TR/qaframespec/. RFC1958 IETFRFC1958:ArchitecturalPrinciplesoftheInternet,B.Carpenter,June 1996.Availableathttp://www.ietf.org/rfc/rfc1958.txt. SPECVAR VariabilityinSpecifications,L.Rosenthal,D.HazalMassieux,Editors,W3C WorkingDraft(workinprogress),30August2004, http://www.w3.org/TR/2004/WDspecvariability20040830/.Latestversion availableathttp://www.w3.org/TR/specvariability/. UAAG10 UserAgentAccessibilityGuidelines1.0,J.Gunderson,I.Jacobs,E.Hansen, Editors,W3CRecommendation,17December2002, www.w3.org/TR/2004/RECwebarch20041215/#uribenefits http://www.w3.org/TR/2002/RECUAAG1020021217/.Latestversion

51/52

09/10/12

Architecture of the World Wide Web, Volume One

http://www.w3.org/TR/2002/RECUAAG1020021217/.Latestversion availableathttp://www.w3.org/TR/UAAG10/. WCAG20 WebContentAccessibilityGuidelines2.0,W.Chisholm,J.White,B. Caldwell,et.al.,Editors,W3CWorkingDraft(workinprogress),30July2004, http://www.w3.org/TR/2004/WDWCAG2020040730/.Latestversion availableathttp://www.w3.org/TR/WCAG20/. WSA WebServicesArchitecture,D.Booth,F.McCabe,E.Newcomer,et.al., Editors,W3CNote,11February2004,http://www.w3.org/TR/2004/NOTEws arch20040211/.Latestversionavailableathttp://www.w3.org/TR/wsarch/. XAG XMLAccessibilityGuidelines,S.B.Palmer,C.McCathieNevile,D. Dardailler,Editors,W3CWorkingDraft(workinprogress),03October2002, http://www.w3.org/TR/2002/WDxag20021003.Latestversionavailableat http://www.w3.org/TR/xag.

8.Acknowledgments
ThisdocumentwasauthoredbytheW3CTechnicalArchitectureGroupwhich includedthefollowingparticipants:TimBernersLee(coChair,W3C),TimBray (AntarcticaSystems),DanConnolly(W3C),PaulCotton(MicrosoftCorporation), RoyFielding(DaySoftware),MarioJeckle(DaimlerChrysler),ChrisLilley(W3C), NoahMendelsohn(IBM),DavidOrchard(BEASystems),NormanWalsh(Sun Microsystems),andStuartWilliams(coChair,HewlettPackard). TheTAGappreciatesthemanycontributionsontheTAG'spublicmailinglist, wwwtag@w3.org(archive),whichhavehelpedtoimprovethisdocument. Inaddition,contributionsbyDavidBooth,ErikBruchez,KendallClark,KarlDubost, BobDuCharme,MartinDuerst,OlivierFehr,AlGilman,TimGoodwin,Elliotte RustyHarold,TonyHammond,SandroHawke,RyanHayes,DominiqueHazal Massieux,MasayasuIshikawa,DavidM.Karr,GrahamKlyne,JacekKopecky,Ken Laskey,SusanLesch,HkonWiumLie,FrankManola,MarkNottingham,Bijan Parsia,PeterF.PatelSchneider,DavidPawson,MichaelSperbergMcQueen, PatrickStickler,andYuxiaoZhaoaregratefullyacknowledged.

www.w3.org/TR/2004/RECwebarch20041215/#uribenefits

52/52