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)