Proposed Design Principles updated

Hey everyone,

I did some clean-up of the text, added a brief introduction  
explaining the document, and tried to express opposing viewpoints for  
disputed principles. I also added a few more principles that have  
been discussed directly to the disputed section.

I also reviewed AWWW <http://www.w3.org/TR/webarch/> to see which of  
their recommendations we could adopt. Many are not directly relevant  
to HTML, since they are mainly about URIs and resource  
representations and such. I did find the following which are  
relevant, but I'm not sure they merit additions to our list. Here is  
how I would classify them:


The following are in direct opposition to principles on our list:
------------

* Constraint: Data-metadata inconsistency
Agents MUST NOT ignore message metadata without the consent of the user.

(The cited example of warning about or refusing to render a jpeg with  
a type of image/gif would violate Don't Break The Web and is unlikely  
to be implemented.)

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

(This is opposed to Handle Errors and our charter goals to handle tag  
soup.)


We've already included the following (in some cases as Disputed):
------------

* Good practice: Version information
A data format specification SHOULD provide for version information.

(The justification for this is that multiple versions of data formats  
and user agents may be in use at the same time, but the compatibility  
principles would address that without the need for versioning.  
Currently in Disputed section.)

* Good practice: Extensibility mechanism
A specification SHOULD provide mechanisms that allow any party to  
create extensions.

(Currently in Disputed section pending clarification.)

* Good practice: Unknown extensions
A specification SHOULD specify agent behavior in the face of  
unrecognized extensions.

(Covered by Well-Defined Behavior and Handle Errors.)

* Good practice: Extensibility conformance
Extensibility MUST NOT interfere with conformance to the original  
specification.

(Presumably would be covered by Support Extensions but note that HTML  
extension by adding new tags and attributes does currently interfere  
with conformance of the document. Not clear if that is what the "Good  
practice" has in mind.)

* Good practice: Separation of content, presentation, interaction
A specification SHOULD allow authors to separate content from both  
presentation and interaction concerns.

(Covered by Mostly Semantic Markup, currently disputed.)


The following seem like good ideas but are unlikely to affect  
decisions about the language:
-----------

* Good practice: Namespace policy
An XML format specification SHOULD include information about change  
policies for XML namespaces.

* Principle: Orthogonality
Orthogonal abstractions benefit from orthogonal specifications.


The following are true for HTML and so obvious that they extremely  
unlikely to be changed, so I don't think they need a mention outside  
AWWW:
-----------

* Good practice: Link identification
A specification SHOULD provide ways to identify links to other  
resources, including to secondary resources (via fragment identifiers).

* Good practice: Web linking
A specification SHOULD allow Web-wide linking, not just internal  
document linking.

* Good practice: Generic URIs
A specification SHOULD allow content authors to use URIs without  
constraining them to a limited set of URI schemes.

* Good practice: Hypertext links
A data format SHOULD incorporate hypertext links if hypertext is the  
expected user interface paradigm.

(Regarding the above four, obviously HTML supports hypertext links  
and general linking.)

* Good practice: Namespace adoption
A specification that establishes an XML vocabulary SHOULD place all  
element names and global attribute names in a namespace.

(We have a namespace, removing it seems extremely unlikely to be  
proposed.)

* Constraint: QNames Indistinguishable from URIs
Do not allow both QNames and URIs in attribute values or element  
content where they are indistinguishable.

(HTML doesn't have any QName-valued attribute values or element  
content, let alone overloaded on the same attribute / element so we  
can probably leave this to AWWW to cover.)

Received on Tuesday, 3 April 2007 07:26:11 UTC