Web Arch principles, constraints, and GPNs

(Contrary to Tim's assertion at TPAC, I hadn't sent this to www-tag,
but I probably should have. Here it is, in any event. :-)

I took a look through all of the principles, constraints, and good
practice notes in Web Arch volume 1. The tone of the discussion [on
the TAG telcon] about this area from a few weeks ago left me worried
that I might find half of them were no longer defensible.

In fact, I think I'm still willing to stand behind them all. Perhaps
we were a little speculative about versioning, perhaps a MUST here or
there might better be a SHOULD, but I think, on the whole, they still
apply.

Here they are.

Principles:

  Global naming leads to global network effects.

  Agents do not incur obligations by retrieving a representation.

  An application developer or specification author SHOULD NOT require
  networked retrieval of representations each time they are referenced.

  Orthogonal abstractions benefit from orthogonal specifications.

  Agents that recover from error by making a choice without the user's
  consent are not acting on the user's behalf.

Constraints:

  Assign distinct URIs to distinct resources.

  Agents MUST NOT ignore message metadata without the consent of the user.

  Do not allow both QNames and URIs in attribute values or element
  content where they are indistinguishable.

Good practices:

  To benefit from and increase the value of the World Wide Web, agents
  should provide URIs as identifiers for resources.

  A URI owner SHOULD NOT associate arbitrarily different URIs with the
  same resource.

  An agent that receives a URI SHOULD refer to the associated resource
  using the same URI, character-by-character.

  A specification SHOULD reuse an existing URI scheme (rather than
  create a new one) when it provides the desired properties of
  identifiers and their relation to resources.

  Agents making use of URIs SHOULD NOT attempt to infer properties of
  the referenced resource.

  New protocols created for the Web SHOULD transmit representations as
  octet streams typed by Internet media types.

  Server managers SHOULD allow representation creators to control the
  metadata associated with their representations.

  A URI owner SHOULD provide representations of the resource it
  identifies

  A URI owner SHOULD provide representations of the identified
  resource consistently and predictably.

  A data format specification SHOULD provide for version information.

  An XML format specification SHOULD include information about change
  policies for XML namespaces.

  A specification SHOULD provide mechanisms that allow any party to
  create extensions.

  Extensibility MUST NOT interfere with conformance to the original
  specification.

  A specification SHOULD specify agent behavior in the face of
  unrecognized extensions.

  A specification SHOULD allow authors to separate content from both
  presentation and interaction concerns.

  A specification SHOULD provide ways to identify links to other
  resources, including to secondary resources (via fragment
  identifiers).

  A specification SHOULD allow Web-wide linking, not just internal
  document linking.

  A specification SHOULD allow content authors to use URIs without
  constraining them to a limited set of URI schemes.

  A data format SHOULD incorporate hypertext links if hypertext is the
  expected user interface paradigm.

  A specification that establishes an XML vocabulary SHOULD place all
  element names and global attribute names in a namespace.

  The owner of an XML namespace name SHOULD make available material
  intended for people to read and material optimized for software
  agents in order to meet the needs of those who will use the
  namespace vocabulary.

  A specification in which QNames serve as resource identifiers MUST
  provide a mapping to URIs.

  In general, a representation provider SHOULD NOT assign Internet
  media types beginning with "text/" to XML representations.

  In general, a representation provider SHOULD NOT specify the
  character encoding for XML data in protocol headers since the data
  is self-describing.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Simplicity is always a virtue.--Edward
http://nwalsh.com/            | Abbey