Hello, 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 [1]] 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 designer" 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 Dom 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 http://esw.w3.org/topic/RfcKeywords 2. http://www.w3.org/TR/chips -- Dominique Hazaël-Massieux - http://www.w3.org/People/Dom/ W3C/ERCIM mailto:dom@w3.org <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>
</xsl:text> </xsl:for-each> </xsl:template> </xsl:stylesheet> * 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 semantics. * practice: Publishers of a URI SHOULD provide representations of the identified resource consistently and predictably. * 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 concerns. * 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 linking. * 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 representations. * 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