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 tactical 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 anticipate and respond to and challenges and provide leadership. If it were 1988 and one had to design the Web, what would the design objectives be? How do we distinguish core values from inertia? When the TAG runs into community resistance or conceptual quagmires, is this to be chalked up to a problem with the objectives, or to a matter of implementation tactics? That is, should we change what we are trying to do, or just the ways in which we're trying to do it?
To create this table, I scanned all of AWWW and tried to eke out the objectives, independent of accidents of implementation. I did this by looking for places where AWWW gave reasons for architectural choices or good practices. After scanning AWWW I went over the list of findings and the open and pending review issues in a similar way.
Brackets [] mark JAR's personal interpretations (usually).
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.
The intended purpose of the table is to provide a tool for internal use within the TAG to help improve effectiveness. If developed it may have other potential purposes as well, e.g. transparency or outreach.
| Objective: | "Webarch classic" approach: | Realization: | AWWW section: | Findings and issues: |
| 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 | the WWW over Internet: HTTP, HTML, etc. | abstract | |
| preserve these properties of the information space [i.e. investment in it?] as the technologies evolve | extension points, orthogonal design | extensibility via media types, HTTP headers, HTML names, etc. | abstract, orthogonal specs | Scheme and protocols (draft finding) (where to put this?), 49, 66 media types |
| foster global network effects | support linking anything to anything | use URIs for all kinds of references | 2.1 URIs, 4.4 hypertext | |
| support linking and bookmarking | [exhortation] | URIs | 2.1 URIs, 3.5.1 persistence | |
| facilitate caching [sameness detection] | safe interaction | GET, Expires:, etags | 2.3 comparisons, 3.4 safe interactions | |
| support indexing by search engines | discriminate between various kinds of success/failure outcomes [??] | forms, CGI, (robots.txt) | 5.3 error handling ??? (other places?) | 63 metadata |
| reduce the risk of semantic collision | namespace "ownership" and "delegation" ideas; ideal of single namespace | URI scheme registration, media type registration, domain name registration, fragids "depend on" media type | 2.2 URI/resource, 2.4 URI schemes, 3.2 media types, 4.5.5 qnames, 4.5.6 xml ids | secondary resources (43), 1 |
| allow either client-side and server-side interpretation [of links that is. provider's choice?] | query string / fragment identifier distinction in URI | 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 | Metadata in URIs [where to put this?], 31, 56 | |
| open-ended space of potential interactions between parties connected by a network | deliberately build in extension points | request methods in HTTP ?? | 3 interaction | |
| abstraction and negotiation over the mode and details of interactions (language, sensory modes, etc.) | HTTP 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; transparency; rule of law] | specifications, type and version indicators, registries for same[, web as registry, maybe] | URI schemes, Content-type:, URI-based discovery | 3.1.1 details, 4.5.4 namespace documents?? | Metadata in URIs [where to put this?], Namespace documents, Self-describing Web, 14 range of dereference function, 39 URIs in RDF, 50 URNs and registries, 51, 57 URI documentation |
| 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 | 16 HTTP as a substrate, 24 content type override | |
| [support exploration / speculative action / confidence / noncommitment (how client can predict the effects of commands?)] | safe interactions | 3.4 safe interactions, | Use of HTTP GET and POST | |
| [reasoning at a distance (inference/prediction of useful properties?)] | [exhortation to] consistency between 'representations' over conneg and time... ergo greater utility (reuse etc.) of a link | 3.5 representation management | 53 generic resources | |
| allow control over who's authorized to do what | conventional ABAC (authentication-based access control) not relying on secrecy; orthogonal encryption | [exhortation regarding] "no metadata in URIs" | 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 | URIs designate, application layer authentication (login) | 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 | media types? | 4 formats, 5.3 error handling | 20, 45 granularity |
| abstract over character set (goes to internationalization and content inclusiveness) | character encoding transparency and interconvertibility | text/ media types, charset=, XML [also IRIs??] | 4.1 binary vs. text/, 4.5.7 re text/ (?) | See Internet Media Type registration, consistency of use (?), 27 IRIs everywhere |
| portability and interoperability e.g. between different character sets | 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 | Disposition of names | |
| composition / modularity of formats | namespaces | XML namespaces | 4.2.4 composition of formats, 4.5.3 namespaces | 46 impact of XML changing |
| support "a wide variety of agents provide access to content to users with a wide variety of capabilities" | [exhort] separation of content / presentation / interface | CSS, ARIA, SVG(?) [what else?] | 4.3 separation | |
| durability of infrastructure over time as technologies evolve | document centrism ["documents are long, code is short"], decouple payload from protocol | XML [?] | 4.5.1 when to use XML | 41 extensibility/versioning |
| reuse of information space for novel purposes | orthogonal specifications; designation/protocol independence | URI/HTTP/HTML separation; [exhortation to] scheme/protocol independence | 4.6, 5.1 orthogonal specs | Rule of least power |
| [empower the user (?), support accountability] | [exhortation to] make agents act on user's behalf | XML error policy [?], etc. | 5.3 error handling | Authoritative metadata, 55 |
| low barrier to entry for implementation of agents | [exhortation] identify predictable error conditions | XML error policy [?], etc. | 5.3 error handling | Identifying application state seems related? |
| resilience in face widely varying environments | [exhortation] identify predictable error conditions | XML error policy [?], etc. | 5.4 protocol-based interop | |
| [provide an attractive migration path] | [bootstrap by re-using and assimilating existing infrastructure, as opposed to relying on a revolution and/or a new bureaucracy] | URIs schemes for "legacy" information sources (gopher:, ftp:, wais:); use of Internet domain names in URIs | [not called out in Webarch] | |
| [objective unclear - maybe something to do with Link: or RDF? or network effects?] | [exhortation] map all technical namespaces into the URI namespace | [mostly not acomplished; RDF has qname/URI mapping] | 2.1 Benefits of URIs | URIs/media type mapping, URI/qname mapping, 47 SOAP ??? |
| reduce the number and complexity of languages that need to be understood by programmers, users, and applications | simplify / reuse; implementation is institutional | (proposal to formalize informal practice by CSS, HTML, SVG, and XSL working groups) | property name consistency, 2, 3, 40 URI construction, 54 tag soup, 67 XML/HTML divergence | |
| [situate accountability downstream from the provider of the source in which it occurs ("freedom to link")] | content provider should use technical means to align access control with private and public policy | legal systems | Deep linking, 25 | |
| support mechanization of access [and use] | (a) [exhortation] identify predictable error conditions; (b) provide machine-processable access to structural information about the information space and its content, where possible | XML error policy [?]; provide RDF at affected URI (linked data) | 5.3 error handling | linking alternative representations, namespace documents, 35 RDF in HTML, 62 metadata, 63 metadata |
| [reliable traversal of the information space] | enable mechanical discovery of links occuring in a document (reliable discrimination of intended link from non-link) | e.g. xsd:anyURI in XML Schema | URI/qname mapping. The absence of a DTD finding is on a related topic. | |
| [decouple interface for access from implementation of access??] | dictionaries? install step? (related to caching, content addressibility) | 58 scalability, 61 packaged items | ||
| [orphan issues] | 34 XML transformation, 37 ???, 60 application state |
TBD: review TAG issues list
JAR (latest version, version discussed on 2012-09-13 TAG call)