What are the objectives of Web architecture?

This exercise originates from the discussion of TAG effectiveness at the June 2012 TAG F2F. See TAG ACTION-726.

The idea is that deconvolving the particulars of "classic" Web architecture, as laid out in AWWW, from the values and design objectives that it is meant to support might be helpful as we evaluate how to respond to, and anticipate, changes in the actual architecture. If it were 1988 and one had to design the Web, what would one want to take into consideration? Is it the objectives themselves that are changing, growing, or retreating today, or merely the tactics we use to address them?

To create this table, I scanned all of AWWW and tried to eke out the objectives, independent of accidents of implementation.

It might be useful to have another column in the table connecting to known TAG issues.

Brackets [] mark JAR's personal interpretations of the objectives.

I use the word "exhortation" to call out situations where AWWW does not provide any particular help, but rather just asks everyone to "do the right thing", leaving the crafting of solutions up to participants.

Objective: "Webarch classic" approach: AWWW section:
create "a remarkable information space of interrelated resources, growing across languages, cultures, and media". [I.e. reduce friction in providing and accessing information globally.] global hypermedia network over Internet abstract
preserve these properties of the information space [i.e. investment in it?] as the technologies evolve extension points, orthogonal design abstract, orthogonal specs
foster global network effects link anything to anything (URIs) 2.1 URIs, 4.4 hypertext
support linking and bookmarking URIs, [exhortation] 2.1 URIs, 3.5.1 persistence
facilitate caching [sameness detection] safe GET, Expires: 2.3 comparisons, 3.4 safe interactions
support indexing by search engines forms, CGI, discriminate between various kinds of success/failure outcomes 5.3 error handling ??? (other places?)
reduce the risk of semantic collision URI scheme registration, media type registration, domain name registration, [exhortation to] fragment identifier determinism 2.2 URI/resource, 2.4 URI schemes, 3.2 media types, 4.5.5 qnames, 4.5.6 xml ids
allow both client-side and server-side interpretation (choice) fragment identifiers 2.6 fragids, 4.4.1 URI references
[enable human-mediated transmission and checking of machine-actionable entry points into information space] ("side of bus") URIs are human-readable, memorable, and -writable 2.7.1 IRIs, 4.5.5 qname mappings
open-ended space of potential interactions between parties connected by a network extension points (request methods?) 3 interaction
abstraction and negotiation over the mode and details of interactions (language, sensory modes, etc.) content negotiation 3.1 access using URI
[help an agent designer (communicating party) know it is doing what is expected (the "rules of the road"), as opposed to having to guess or reverse engineer] markers, registries 3.1.1 details, 4.5.4 namespace documents??
support orthogonality of protocol choice and payload format; i.e., allow independent variation of the two URI schemes, media types, conneg 3.2 media types, 3.5 available representations
[support exploration / speculative action / confidence / noncommitment (how client can predict the effects of commands?)] safe interactions 3.4 safe interactions
[reasoning at a distance (inference of useful properties?)] [exhortation to] consistency between 'representations' over conneg and time 3.5 representation management
allow control over who's authorized to do what conventional ABAC (authentication-based access control) not relying on URI secrecy; orthogonal encryption 3.5.2 access control, end of 4.3 separation
support privilege attenuation / sending pointers to private information over public channels separate designation from authorization 3.5.3 navigation support
coordinate agreement on interpretation; reduce amount of context required for interpretation; [support component re-use in specs and infrastructure] data format = agreement on the correct interpretation 4 formats, 5.3 error handling
abstract over character set (goes to internationalization and content inclusiveness) character encoding transparency and interconvertibility, text/ media types, XML [also IRIs??] 4.1 binary vs. text/, 4.5.7 re text/ (?)
portability and interoperability text/ media types, XML 4.1 binary vs. text/
prevent error and preserve investment when protocols and formats evolve ("future-proof") version indicators and change policy articulation 4.2 versioning, 4.2.3 extensibility, 5.2 extensibility
composition / modularity of formats namespaces 4.2.4 composition of formats, 4.5.3 namespaces
support "a wide variety of agents provide access to content to users with a wide variety of capabilities" [exhort] separation of content / presentation / interface 4.3 separation
durability of infrastructure over time as technologies evolve document centrism ["documents are long, code is short"] 4.5.1 when to use XML
reuse of information space orthogonal specifications 4.6, 5.1 orthogonal specs
[empower the user (?), support accountability] [exhortation to] make agents act on user's behalf 5.3 error handling
low barrier to entry for implementation of agents [exhortation] 5.3 error handling
support mechanization of access [exhortation] 5.3 error handling
resilience in face widely varying environments [exhortation] 5.4 protocol-based interop
[bootstrap by re-using and assimilating existing infrastructure, as opposed to relying on a new bureaucracy] gopher:, ftp:, URIs; use of Internet domain names in URIs [not called out in Webarch]

TBD: a few other topics from AWWW e.g. "SVG should only address presentation", and from TAG findings, e.g. authoritative metadata

JAR 2012-09-11. (link to this document)