Let's get some principles nailed down

It is long past time that we went to work on nailing down some of the 
principles that are going to go into the "Representations" and 
"Interactions" section of Webarch.  In the interest of moving this 
discussion along, I've drawn up a bunch of strawman principles.  If we 
could get consensus on a few of these, it would really help move Webarch 
along.  I have deliberately left out a couple where I think we have a 
lot more work to get to consensus; I'm optimistic that on at least a few 
of these we can achieve quick consensus and generate a bunch of grist 
for Ian's mill, and have some more progress to present to the AC on Tuesday.

So here are a bunch of candidate principles, with numbers to facilitate 
discussion.  I acknowledge that the use of the word "principle" is a bit 
dicey since we're arguing about what to call these things.  Let's 
consider it a placeholder here.

Principles on representations:

CP1. When designing a data format to be used in representing Web 
Resources, the use of XML should be considered carefully.

  - some issues concerning XML pros and cons
  - pointer to IETF doc

CP2. When specifying the use of URIs, designers SHOULD NOT constrain the 
use of URI schemes.

CP3. When using XML, designers SHOULD NOT introduce syntax constraints 
beyond those involved in the definition of XML.

CP4. XML-based languages MUST be given a namespace name and the elements 
of the language MUST be placed in that namespace.  Designers SHOULD make 
available a representation of the namespace which is human-readable and 
SHOULD make available a representation which is a machine-readable 
directory of resources which are related to that namesapce.

CP5. For languages whose contents are intended for visual rendering for 
presentation to humans, the repertoire of formatting semantics SHOULD be 
consistent across the universe of W3C recomnmendations.

CP6. When designing a language that includes linking or hypertext 
functionality, designers SHOULD design that functionality so it supports 
Web-side rather than merely local linking.

CP7. Designers of languages which will be used in resource 
representations MUST arrange for the registration of an Internet Media 
Type for that language, and SHOULD consider the recommendations of 
RFC3203 in carrying out that registration.  This registration MUST 
include a specification of the handling of fragment identifiers for 
resource representations in the language being designed.

CP8. Designers of languages which are to be interchanged on the Web MUST 
include a discussion of error-handling, with specific recommendations on 
the correct behavior upon detection of certain classes of errors.

  - example classes: XML well-formedness vs. semantic brokenness (eg SVG
    circle with negative radius)

----------------------------------------------------------

Examples concerning Interaction

CP9. Designers of protocols should invest time in understanding the REST 
paradigm and consider the role to which its principles should guide 
their design:
- statelessness
- clear assignment of roles to parties
- flat addrss space
- limited uniform set of verbs

CP10. Agents which receive a resource representation accompanied by an 
Internet Media Type MUST interpret the representation according to the 
semantics of that Media Type and other header information.  Servers 
which generate representations MUST not generate Media Types and other 
header information (for example charsets) unless there is certainty that 
the headers are correct.

CP11. Designers of protocols should give serious consideration to 
avoiding such design activities in favor of existing well-established 
protocols such as HTTP that fit well into REST.

Received on Monday, 18 November 2002 00:24:14 UTC