W3C home > Mailing lists > Public > public-webarch-comments@w3.org > February 2004

Webarch conformance model

From: Dominique HazaŽl-Massieux <dom@w3.org>
Date: Fri, 20 Feb 2004 13:49:03 +0100
To: public-webarch-comments@w3.org
Message-Id: <1077281343.30689.385.camel@stratustier>

Here comes a more substantive comment on the Webarch document; I've
extracted from the document the list of constraints/principle/good
practices (attached as text) - using a simplistic xslt also attached.
I've tried to analyze the kind of requirements they were creating.

The 'subjects' [1] on which they apply (when defined) are in the last
call version:
* resource owners
* published of a URI
* (web) agents
* user agents
* authors of a specification
* format/language designers
* server managers
* specifications [which probably would be the most contentious wrt to

Here are the issues that I have with these subjects:
* "resource owners" are not defined; the document details the various
ways a URI can be owned depending on its scheme, but it does not tell
what it means to own a resource; the fix might just to defer this
question to other social structures, but I think it is important to
clarify these questions before having the first requirement on "resource
owners"; it would also be a good idea to insist on the difference
between owning a URI and owning the resource identified by this URI

* "publisher of a URI": what is this? Is it the URI owner? Does it need
to be differentiated from the resource owner?

* "agents" vs "user agents": the two terms are used in the conformance
requirements; presumably, the user agents differ from the general agents
case in so that they act on behalf of someone (according to the
definition); but which agents don't?
Said otherwise, for which agents the principle "agents MUST NOT silently
ignore authoritative server metadata" doesn't apply?

* "authors of a specification" vs "language designer" vs "format
The distinction between format and language is said to be null in the
document; I believe that usually, format is associated to the syntactic
part of a language (which also includes the semantics); I think that at
least the terms should be used consistently (ie either 'language
designer' or 'format designer') in the conformance requirements, if only
for ease of reading.
Also, the terms "authors of a specifications" seems to be bound to the
same type of subjects, but probably with a wider scope - maybe is there
a way to merge all these terms in one?

* "server managers"
Recommendations for server managers seems to be misplaced in an
architectural document; I think they should belong to another document
(CHIPs [2] come to my mind)

* there is one instance of conformance requirement applied to
"specifications" (Specifications that use QNames to represent...); I
guess it should be re-targeted to "specification authors" or "language
designer" or something else. Or the contrary, which I would prefer
(except for the note on RFC Keywords usage) - that is, I think the TAG
should define what a "Web-friendly specification" (or coin a better
term) should allow, enforce, constrain. 

(I prefer this approach on the one defining requirements for authors
specifications, since I find it more natural to review a language saying
"it is web-friendly in so that...", "it is not web-friendly in so
that...", than to say "these authors are Web-morons" )

In any case, my general comment is that it would be better to reduce the
list of conformance subjects in the arch document:
- to avoid some of the fuzziness introduced by having non-defined
conformance subjects
- to make it easier for the reader to understand the requirements


1. Some would argue that these subjects should be agents; e.g.
http://www.w3.org/2001/01/mp23 ; I'm not raising an issue on this,
though, since I'm still unclear on all the aspects of it... See also
2. http://www.w3.org/TR/chips
Dominique HazaŽl-Massieux - http://www.w3.org/People/Dom/

<xsl:stylesheet version="1.0" xmlns:html="http://www.w3.org/1999/xhtml" xmlns:xsl='http://www.w3.org/1999/XSL/Transform'>
  <xsl:output method='text'/>
  <xsl:template match="/">
    <xsl:for-each select="/html:html/html:body/descendant::html:*[@class='principle' or @class='practice' or @class='constraint']">
      <xsl:sort select="@class"/>
      * <xsl:value-of select="@class"/>: <xsl:copy-of select="."/><xsl:text>&#x0A;</xsl:text>
      * constraint: The identification mechanism for the Web is
the URI.

      * constraint: Web architecture does not constrain a Web
resource to be identified by a single URI.

      * practice: Resource owners should not create arbitrarily
different URIs for the same resource.

      * practice: If a URI has been assigned to a resource,
agents SHOULD refer to the resource using the same URI, character
for character.

      * practice: Avoid URI ambiguity.

      * practice: Authors of specifications SHOULD NOT introduce
a new URI scheme when an existing scheme provides the desired
properties of identifiers and their relation to resources.

      * practice: Agents making use of URIs MUST NOT attempt to
infer properties of the referenced resource except as licensed by
relevant specifications.

      * practice: A resource owner who creates a URI with a
fragment identifier and who uses content negotiation to serve
multiple representations of the identified resource SHOULD NOT
serve representations with inconsistent fragment identifier

      * practice: Publishers of a URI SHOULD provide
representations of the identified resource consistently and

      * practice: Publishers of a URI SHOULD provide
representations of the identified resource.

      * practice: Format designers SHOULD provide for version
information in language instances.

      * practice: Format designers SHOULD document change
policies for XML namespaces.

      * practice: Language designers SHOULD provide mechanisms
that allow any party to create extensions that do not interfere
with conformance to the original specification.

      * practice: Language designers SHOULD specify agent
behavior in the face of unrecognized extensions.

      * practice: Language designers SHOULD design formats that
allow authors to separate content from presentation and interaction

      * practice: Language designers SHOULD provide mechanisms
for identifying links to other resources and to portions of
representation data (via fragment identifiers).

      * practice: Language designers SHOULD provide mechanisms
that allow Web-wide linking, not just internal document

      * practice: Language designers SHOULD allow authors to use
URIs without constraining them to a limited set of URI schemes.

      * practice: Language designers SHOULD incorporate hypertext
links into a data format if hypertext is the expected user
interface paradigm.

      * practice: Language designers who create new XML
vocabularies SHOULD place all element names and global attribute
names in a namespace.

      * practice: Resource owners who publish 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.

      * practice: Specifications that use QNames to represent
URI/local-name pairs SHOULD NOT allow both forms in attribute
values or element content where they would be indistinguishable
from URIs.

      * practice: Language designers who use QNames as
identifiers of Web resources MUST provide a mapping to URIs.

      * practice: In general, server managers SHOULD NOT assign
Internet Media Types beginning with "text/" to XML

      * practice: In general, server managers SHOULD NOT specify
the character encoding for XML data in protocol headers since the
data is self-describing.

      * principle: Silent recovery from error is harmful.

      * principle: A resource owner SHOULD assign a URI to each
resource that others will expect to refer to.

      * principle: User agents MUST NOT silently ignore
authoritative server metadata.

      * principle: Agents do not incur obligations by retrieving
a representation.

Received on Friday, 20 February 2004 07:59:58 EST

This archive was generated by hypermail pre-2.1.9 : Friday, 20 February 2004 08:00:00 EST