- From: Maciej Stachowiak <mjs@apple.com>
- Date: Tue, 3 Apr 2007 00:26:01 -0700
- To: public-html@w3.org
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