W3C home > Mailing lists > Public > www-tag@w3.org > August 2003

Re: Arch Doc: 1 August 2003 Editor's Draft

From: Roy T. Fielding <fielding@apache.org>
Date: Fri, 8 Aug 2003 18:51:21 -0700
Cc: "Ian B. Jacobs" <ij@w3.org>, www-tag@w3.org
To: Dan Connolly <connolly@w3.org>
Message-Id: <F9C907AA-CA0B-11D7-996C-000393753936@apache.org>
> Hmm... the core terms from the introduction have been
> substantially changed...
>
> |The World Wide Web (WWW, or simply Web) is an information system
> |that relates information sources and services, referred to
> |collectively as resources ...
>
> That defines resources as information sources and services
> and nothing else; that's a substantive change from the earlier text,
> which I thought was quite mature:
>
> |Objects in the networked information system called resources
> |are identified by Uniform Resource Identifiers (URIs).
>   -- http://www.w3.org/2001/tag/2003/webarch-20030716
>
> it placed no constraints on what a resource is.

Actually, it places the same constraints -- they just get missed by
the noise.  All I did was rewrite the sentence to reflect what it was
actually saying.  In my message to the TAG, I said it was wrong because
it defined the Web as an information system rather than an information
space.  The changes that Ian applied do not change that, nor will
removing them improve it.

> Where did this change come from? The changelog says...
>
> 1. Introduction: Incorporated text suggested by Roy Fielding."
>   -- http://www.w3.org/2001/tag/webarch/changes#changes-20030801
>
> i.e. this change came from work-in-progress from one tag member,
> sent only to the tag private list, with no endorsement from
> anybody else, that I can see.
>
> That seems like a big step backward from the level
> of maturity section 1 had as of the Vancouver meeting.

That portrayal is incorrect.  We didn't discuss it in Vancouver
because we had already discussed it in Irvine, at which point both
myself and TimBL said that the section needed to be rewritten.
It is still in a very immature state.

> Hmm... I'm disappointed to see that the record of the Vancouver
> meeting doesn't record
>   -- my request that the review of each section
>   not assume that everybody agreed to everything unless
>   they said otherwise; that we solicit endorsements
>   as well as criticisms
>
>   -- my endorsement (and Tim Bray's, if not lots
>   of others') of the text of the intro section,
>   and the definitions of the core terms in particular.

Was that before I arrived?  I have no recollection of it.  In any case,
I introduced my changes during that meeting.

> So as a reviewer like any other reviewr, I ask:
> please undo this change and put back the intro text
> that was there before.
>
> And I ask the chairs to work with the editor to reduce
> churn. Let's not have half a suggestion by one TAG member
> turn into substantive changes to text that has been
> endorsed previously by multiple TAG members. Let's please
> be especially careful with the definitions of the
> marked-up terms.

Bah!  In that case, let's also be careful to waste our time with
procedural details whenever Dan disagrees with a change, rather
than actually attempt to fix some of the utter nonsense in the
webarch document that makes it nearly impossible to review.

I rescind my abstention and vote against this draft being
published as a TAG draft until the abstract and introduction
is rewritten to be at least halfway sensible by avoiding the
creation of new terms that nobody outside the W3C use to
describe software architecture, ceasing to redefine existing terms
such that the WWW information system and Semantic Web cannot be
distinguished from the Web of relationships between resources,
and including human behavior as being within the scope of the
system that is being described.  And while you are at it, please
feel free to improve the grammar and prose.

Below are some relevant suggestions that were posted before in
private mail.  The problem with defining the Web as an information
system rather than an information space is that people start
making global assumptions about traits that are only applicable
to one system that uses the Web of resources.  Thus, I don't like
the definition of Web given in the current document and merely
rephrased here -- it needs to be changed to refer to the Web as
the set of explicitly related resources and some new term has to
be created to refer to the WWW information system.  That will allow
the differences between the WWW, SW, and WS architectures to be
properly explained in the document, rather than continuing pointless
arguments about how WWW constraints might impact the SW.

Note that most of these changes are simply placing quotes around
URIs that appear in text so that they are properly recognized and
delimited from the surrounding punctuation.  Feel free to replace
them with angle brackets, as recommended by all URI specifications
since 1994, but quotes are easier when dealing with XML transforms.

....Roy


Index: webarch.html
===================================================================
RCS file: /w3ccvs/WWW/2001/tag/webarch/webarch.html,v
retrieving revision 1.84
diff -u -r1.84 webarch.html
--- webarch.html	17 Jul 2003 00:23:42 -0000	1.84
+++ webarch.html	22 Jul 2003 17:19:43 -0000
@@ -75,19 +75,19 @@
 <div class="section">
 <h2 class="notoc"><a name="abstract" id="abstract">Abstract</a></h2>
 
-<p>The World Wide Web is a networked information system. Web
-Architecture consists of the requirements, constraints, principles,
-and choices that influence the design of the system and the behavior
-of agents within the system. When Web Architecture is followed, the
-large-scale effect is that of an efficient, scalable, shared
-information space. The organization of this document reflects the
-three divisions of Web architecture: identification, representation,
-and interaction. This document also addresses some non-technical
-(social) issues that play a role in building 
-the shared information space.</p>
-
-<p>This document strives to establish a reference set of requirements,
-constraints, principles, and design choices for Web architecture.</p>
+<p>The World Wide Web is an information system that relates
+information sources and services through the use of hypertext-style
+relationships, creating a web of information that spans the Internet.
+Architecture defines the desired operational behavior of components
+within the system, including software, machine, and human components,
+and protocols for interactions between components.  The Web architecture
+is influenced by social requirements and software engineering principles,
+leading to design choices that constrain the behavior of the Web in order
+for the system to achieve desired properties: an efficient, scalable,
+shared information space that will continue to grow indefinitely
+across languages, cultures, and information mediums.  This document
+is organized to reflect the three dimensions of Web architecture:
+identification, representation, and interaction.</p>
 </div>
 
 <div class="section">
@@ -100,7 +100,13 @@
 
 <p>This document has been developed
 by W3C's <a href="http://www.w3.org/2001/tag/">Technical Architecture Group
-(TAG)</a> (<a href="http://www.w3.org/2001/07/19-tag">charter</a>).</p>
+(TAG)</a> (<a href="http://www.w3.org/2001/07/19-tag">charter</a>).
+Please send comments on this document to the public W3C TAG mailing list
+<a href="mailto:www-tag@w3.org">www-tag@w3.org</a> (<a
+href="http://lists.w3.org/Archives/Public/www-tag/">archive</a>).
+A complete <a href="/2001/tag/webarch/changes">list of
+changes</a> since the previous Working Draft is available on the
+Web. </p>
 
 <p>This draft is an Editor's Draft and some new content has not yet
 been reviewed by the TAG. The primary changes in this draft were
@@ -116,27 +122,21 @@
 specific architecture issues. Parts of those findings may appear in
 subsequent drafts.  Please also consult the <a
 href="http://www.w3.org/2001/tag/ilist">list of issues</a> under
-consideration by the TAG.</p>
-
-<p>This draft includes some editorial notes and also references to open <a
+consideration by the TAG.
+This draft includes some editorial notes and also references to open <a
 href="http://www.w3.org/2001/tag/ilist">TAG issues</a>. These do not
 represent all open issues in the document. They are expected to disappear
 from future drafts.</p>
 
-<p>Publication as a Working Draft does not imply endorsement by the W3C
-Membership. This is a draft document and may be updated, replaced or
-obsoleted by other documents at any time. It is inappropriate to cite this
-document as other than "work in progress."</p>
-
 <p>The latest information regarding <a rel="disclosure" href="/2001/tag/disclosures">patent
 disclosures related to this document</a> is available on the Web. As of this
 publication, there are no disclosures.</p>
 
-<p>Please send comments on this document to the public W3C TAG mailing list
-<a href="mailto:www-tag@w3.org">www-tag@w3.org</a> (<a
-href="http://lists.w3.org/Archives/Public/www-tag/">archive</a>).</p>
-
-<p>A <a href="http://www.w3.org/TR/">list of current W3C Recommendations and
+<p>Publication as a Working Draft does not imply endorsement by the W3C
+Membership. This is a draft document and may be updated, replaced or
+obsoleted by other documents at any time. It is inappropriate to cite this
+document as other than "work in progress."
+A <a href="http://www.w3.org/TR/">list of current W3C Recommendations and
 other technical documents</a> can be found at the W3C Web site.</p>
 </div>
 
@@ -155,11 +155,18 @@
 <div class="section">
 <h2><a id="intro" name="intro">Introduction</a></h2>
 
-<p>The World Wide Web (or, Web) is a networked information system
-consisting of <dfn title="agent" id="def-agent">agents</dfn> (programs
-acting on behalf of a person, entity, or process) that exchange
-information. Here's a simple <a name="scenario" id="scenario">travel
-scenario</a> illustrating a common Web interaction:</p>
+<p>The World Wide Web (WWW, or simply Web) is an information system
+that relates information sources and services, referred to collectively
+as <dfn title="resource" id="def-resource">resources</dfn>, through
+the use of hypertext-style relationships, creating a web of information
+that spans the Internet.  The Web's primary goal is to create and
+maintain an efficient, scalable, shared information space that will
+continue to grow indefinitely across languages, cultures, and
+information mediums.</p>
+
+<p>A simple <a name="scenario" id="scenario">travel scenario</a>
+is used throughout this document to illustrate typical behavior of Web
+components and describe their interactions:</p>
 
 <ul>
 <li>While planning a trip to Mexico, Dan reads
@@ -167,57 +174,73 @@
 <code>http://weather.example.com/oaxaca</code>"
 in a glossy travel magazine. Dan has enough
 experience with the Web to recognize that
-<code>http://weather.example.com/oaxaca</code> is a URI.
-He can expect that the URI should allow him to access
-relevant weather information.</li>
-<li>Dan enters the URI into his browser, which downloads information.
+"<code>http://weather.example.com/oaxaca</code>" is a URI.
+Given the context in which the URI is referred, he can expect that
+it should allow him to access relevant weather information.</li>
+<li>Dan enters the URI into his browser, which performs an information
+retrieval action in accordance with its configured behavior for
+resources identified via the "http" URI scheme.
 The information is provided by those responsible for 
-<code>weather.example.com</code>.</li>
-<li>Dan's user agent displays the downloaded
-information. The page may include links to other information
-(i.e., more URIs) allowing Dan to start the cycle again.</li>
+"<code>weather.example.com</code>".</li>
+<li>Dan's user agent displays the retrieved information as a
+"Web page", which includes links to other information via additional
+URI references, allowing Dan to continue the cycle.</li>
 </ul>
 
-<p>This scenario illustrate the three architectural divisions
-of the Web that are discussed in this document:</p>
+<p>The scenario illustrates three dimensions of Web architecture
+that are discussed in this document:</p>
 
 <ol>
-  <li><a href="#identification">Identification</a>. Objects
-    in the networked information system called <dfn title="resource" 
-    id="def-resource">resources</dfn> are identified
-    by Uniform Resource Identifiers
-    (<acronym>URIs</acronym>). The URI in the travel scenario is
-    <code>http://weather.example.com/oaxaca</code>.
-    </li>
-  <li><a href="#representations">Representation</a>. Agents (such
-    as servers, browsers and multimedia players) 
-    communicate resource state through a non-exclusive set of data
-    formats, used separately or in combination (e.g., XHTML, CSS, PNG, XLink,
-    RDF/XML, SVG, SMIL animation). In the travel scenario, Dan's user
-    agent uses the URI to request a representation of the identified
-    resource. In this scenario, the representation consists of
-    XHTML with embedded weather maps in SVG.
-    </li>
-  <li><a href="#interaction">Interaction</a>. Agents exchange representations
-    via a non-exclusive set of protocols, including HTTP, FTP, and SMTP<span
-    class="note" id="smtp1">@@Text here on why SMTP part of
-Web@@</span>.
-    In the travel scenario, Dan's browser uses HTTP to
-    download the representation.<span class="note"
-  id="uris-and-protocols">Although many URI schemes are named after
-  protocols, this does not imply that use of such a URI will result in
-  access to the resource via the named protocol. When a URI is used to
-  retrieve a representation of a resource, that access might be
-  through gateways, proxies, caches, and name resolution services that
-  are independent of the protocol associated with the scheme name, and
-  the resolution of some URIs may require the use of more than one
-  protocol (e.g., both DNS and HTTP are typically used to access an
-  "http" URI's origin server when a representation isn't found in a
-  local cache). Other protocols than HTTP may be used to interact
-  with a resource identified by an HTTP URI.</span>
+  <li><a href="#identification">Identification</a>. Each resource is
+    identified by a Uniform Resource Identifier (<acronym>URI</acronym>).
+    In the travel scenario, Dan enters a URI into his user agent (browser)
+    and commands it to perform a retrieval action for the identified resource. 
+    The user agent uses its configuration to determine how to locate the
+    identified information, which may be via a cache of prior retrieval
+    actions, by contacting an intermediary, or by direct access to the
+    information authority defined by the URI.  User agent configurations
+    are usually defined by URI scheme, with exceptions defined by further
+    substring matches within the URI.</li>
+
+  <li><a href="#representation">Representation</a>. Components (e.g.,
+    servers, proxies, browsers, spiders, multimedia players, etc.)
+    using the Web communicate via messages that exchange representations
+    of resource information, corresponding to the state of an identified
+    resource, the content of a data-entry form, or the status of an action.
+    A representation communicates information through a non-exclusive
+    set of data formats, used separately or in combination (e.g., XHTML,
+    CSS, PNG, XLink, RDF/XML, SVG, SMIL animation, etc.). In this scenario,
+    the representations consist of an XHTML document and several
+    SVG weather map images.</li>
+
+  <li><a href="#interaction">Interaction</a>. Components exchange
+    representations via a non-exclusive set of messaging protocols
+    (e.g., HTTP, FTP, NNTP, SMTP, etc.) in accordance with actions
+    requested by a user or called for by the rendering engine while
+    processing hypermedia-aware data formats.  Protocols define the
+    syntax and semantics of component interactions, as well as the
+    sequence of interactions expected for a given task.  In the travel
+    scenario, Dan's browser uses HTTP to retrieve a representation
+    from the origin server at "weather.example.com" and interprets the
+    rendering instructions found within the XHTML representation, which
+    in turn calls for retrieval of weather maps through reference of
+    their URIs, which results in rendering the SVG images.  The final
+    rendered result of these interactions, referred to as a
+    <dfn title="webpage" id="def-webpage">Web page</dfn>, is defined
+    by the application steady-state between the last interaction and
+    the next user request.
    </li>
 </ol>
 
+<p>Architecture defines the desired operational behavior of components
+within the system, including software, machine, and human components,
+and protocols for interactions between components.  The Web architecture
+is influenced by social requirements and software engineering principles,
+leading to design choices that constrain the behavior of the Web in order
+for the system to achieve desired properties.  This document is an ongoing
+attempt to describe the properties we desire of the Web and
+the design choices that have been made to achieve them.</p>
+
 <p><span class="ednote">Editor's note</span>: Todo: Introduce notions
 of client and server. Relation of client to agent and user
 agent. Relation of server to resource owner.</p>
@@ -227,7 +250,7 @@
 
 <p>The intended audience for this document includes:</p>
 <ol>
-  <li>Participants in W3C Activities, i.e., developers
+  <li>Participants in W3C Activities; i.e., developers
       of Web technologies and specifications in W3C.</li>
   <li>Other groups and individuals developing technologies to be integrated
     into the Web.</li>
@@ -368,8 +391,8 @@
 licensed to do (e.g., by specification, or community convention, or
 site-specific convention) take responsibility for any problems that
 result.  For instance, agents should not assume that
-<code>http://weather.example.com/Oaxaca</code> and
-<code>http://weather.example.com/oaxaca</code> identify the same
+"<code>http://weather.example.com/Oaxaca</code>" and
+"<code>http://weather.example.com/oaxaca</code>" identify the same
 resource, since none of the specifications involved states that the
 path part of an HTTP URI is case-insensitive. Web servers may vary in
 how they are configured to handle case-sensitivity. Agents that assume
@@ -390,8 +413,8 @@
 it follows that URI producers should be conservative about the number
 of different URIs they produce for the same resource. For instance,
 the parties responsible for weather.example.com have no reason to use
-both <code>http://weather.example.com/Oaxaca</code> and
-<code>http://weather.example.com/oaxaca</code> to refer to the same
+both "<code>http://weather.example.com/Oaxaca</code>" and
+"<code>http://weather.example.com/oaxaca</code>" to refer to the same
 resource; agents will not detect the equivalence relationship. In this
 case, one URI should be chosen and used consistently.  See section 6.3
 of [<a href="#URI">URI</a>] for further advice on how to reduce the
@@ -400,7 +423,7 @@
 <p>URI consumers cannot, in general, determine the meaning of a
 resource by inspection of a URI that identifies it. In our <a
 href="#scenario">travel scenario</a>, the example URI
-(<code>http://weather.example.com/oaxaca</code>) suggests that the
+"<code>http://weather.example.com/oaxaca</code>" suggests that the
 identified resource has something to do with the weather in
 Oaxaca. Although short, meaningful URIs benefit people, URI consumers
 must not rely on the URI string to communicate the meaning of a
@@ -483,7 +506,7 @@
 authority providing information about the weather in Oaxaca register a
 new URI scheme "weather" for the identification of resources related
 to the weather? They might then publish URIs such as
-<code>weather://travel.example.com/oaxaca</code>. While the Web
+"<code>weather://travel.example.com/oaxaca</code>". While the Web
 Architecture allows the definition of new schemes, there is a cost to
 registration and especially deployment of new schemes. When an agent
 dereferences such a URI, if what really happens is that HTTP GET is
@@ -577,9 +600,9 @@
 
 <p>In our <a href="#scenario">travel scenario</a> the server returns
 an XHTML representation when Dan dereferences the URI
-<code>http://weather.example.com/oaxaca</code>. Then, by navigating
+"<code>http://weather.example.com/oaxaca</code>". Then, by navigating
 within the XHTML content, Dan finds that the URI
-<code>http://weather.example.com/oaxaca#tom</code> refers to
+"<code>http://weather.example.com/oaxaca#tom</code>" refers to
 information about tomorrow's weather in Oaxaca. This URI includes the
 fragment identifier "tom" (the string after the "#").</p>
 
@@ -599,7 +622,7 @@
 
 <p>For URI schemes that do specify the use of fragment identifiers,
 the syntax and semantics of those identifiers is defined by the set of
-<a href="#representations">representations</a> that might result from
+<a href="#representation">representations</a> that might result from
 a <a href="#def-representation-retrieval">retrieval</a> action on the
 primary resource. The presence of a fragment identifier component in a
 URI does not imply that a retrieval action will take place.</p>
@@ -619,13 +642,13 @@
 <p>Suppose that the managers of <code>weather.example.com</code>
 provide a visual map of the meteorological conditions in Oaxaca as part
 of the representation served for
-<code>http://weather.example.com/oaxaca</code>. They might encode the
+"<code>http://weather.example.com/oaxaca</code>". They might encode the
 same visual map in a number of image formats to meet different needs
 (e.g., they might serve PNG, SVG, and JPEG/JFIF). Dan's user
 agent and the server engage in HTTP content negotiation, so that Dan
 receives the best image format his user agent can handle or the format
 he usually prefers. The URI
-<code>http://weather.example.com/oaxaca/map#zicatela</code> refers to
+"<code>http://weather.example.com/oaxaca/map#zicatela</code>" refers to
 a portion of the weather map that shows the Zicatela Beach, where Dan
 intends to go surfing. Clients can do something useful with
 the fragment identifier and the SVG representation, since SVG defines fragment 
@@ -698,7 +721,7 @@
 a Representation</a></h4>
 
 <p>One of the most important actions involving a resource is to retrieve a <a
-href="#representations">representation</a> of it (for
+href="#representation">representation</a> of it (for
 example, by using HTTP GET). As stated above, the <a
 href="#URI-authority">authority responsible for a URI</a> determines
 what the URI identifies and which representations are used for
@@ -987,7 +1010,7 @@
 </div>
 
 <div class="section">
-<h2><a id="representations" name="representations">Representations</a></h2>
+<h2><a id="representation" name="representation">Representation</a></h2>
 
 <p>A <dfn title="representation" id="def-representation">representation</dfn>
 is data that represents or describes 
@@ -1025,7 +1048,7 @@
     requests at all;</li>
   <li>Whether the agents responsible for <code>weather.example.com</code>
       make available one or more representations for the resource 
-      identified by <code>http://weather.example.com/oaxaca;</code></li>
+      identified by "<code>http://weather.example.com/oaxaca</code>";</li>
   <li>Whether Dan has access privileges to such a representation; </li>
   <li>If the agents responsible for <code>weather.example.com</code> have provided more
     than one representation (in different formats such as HTML, PNG, or RDF,
Received on Friday, 8 August 2003 21:51:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:20 GMT