comments on NM mods: sec 1

On Oct 14, 2004, at 12:01 PM, noah_mendelsohn@us.ibm.com wrote:
> For those not at our meeting, the intention was that I would fork a
> private copy of the document and edit it to show proposed changes.   
> This
> note fulfulls that action;  a revised draft is attached.

As much as I like seeing the changes in context, I'll extract them
in order to make comments.  And since it takes me a day to complete
a single comment, I am going to split them into chunks.

Sec 1, scenario intro:

   2. Interaction. Web agents communicate the information state
      of a resource using protocols. Protocols define the syntax
      and semantics of messages exchanged by agents over a network.
      By typing the URI into her browser, or clicking on a hypertext
      link, Nadia tells her browser to request the information
      state of the resource referenced by the URI in the link.
      In this example, the browser sends an HTTP GET request to
      the server at "weather.example.com" and the server sends
      back a representation of the information state of the resource.
      In this example, the representation includes XHTML data and
      metadata such as the Internet media type of the data,
      "application/xhtml+xml". Note: In this document, the noun
      "representation" means "[{NOAH>} Machine readable data that
      encodes resource state information".  Web representations
      do not necessarily describe the resource, portray a
      likeness of the resource, or represent the resource in
      other colloquial {<NOAH}] senses of the word "represent".

I am not fond of the original paragraph, but it makes sense in the
limited extent of describing this specific scenario.  I think the
attempt to describe interactions-in-general within the scenario intro
is a mistake, and Noah's change only highlights it. Representations
do represent the resource in the colloquial senses of that word,
so I have no idea why that was added to the introduction.

What I would suggest is:

   2. Interaction. Web agents communicate using standardized protocols
      that enable interaction through the exchange of messages that
      adhere to a defined syntax and semantics. By entering a URI into
      a retrieval dialog or selecting a hypertext link, Nadia tells her
      browser to perform a retrieval action for the resource identified
      by the URI.  In this example, the browser sends an HTTP GET request
      to the server at "weather.example.com", via TCP/IP port 80, and the
      server sends back a message containing what it determines to be
      a representation of the resource as of the time that representation
      was generated.  Note that this example is specific to hypertext
      browsing of information -- other kinds of interaction are possible,
      both within browsers and through the use of other types of Web 
agent;
      our example is intended to illustrate one common interaction, not
      define the range of possible interactions or limit the ways in
      which agents might use the Web.

[There is no reason to define representation here.  However, the next
paragraph (that Noah did not modify) should be changed accordingly:]

   3. Formats. Most protocols used for representation retrieval and/or
      submission make use of a sequence of one or more messages, which
      taken together contain a payload of representation data and 
metadata,
      to transfer the representation between agents.  Each interaction
      protocol defines its own mechanisms for determining the format of
      data and metadata transferred.  HTTP, for example, uses the
      "Content-Type" and "Content-Encoding" header fields to indicate
      the format of representation data. In order to maximize
      interoperability and platform independence, representation data
      is usually formatted according to a standardized data format,
      or several standardized formats in cases such as layered encodings,
      package formats, and multiple data streams.  In this scenario,
      the representation is transferred in the XHTML data format, as
      would be indicated by a "Content-Type" header field containing
      the value "application/xhtml+xml", a registered Internet media type
      that indicates the representation data should be processed 
according
      to the XHTML specification.

[The story doesn't mention any maps, but given the old content of the
  paragraph (3) it must have at one point referred to in-line map images
  in SVG format.  If that part is added back, then we should also say:]

      Nadia's browser is configured and programmed to interpret the
      receipt of an "application/xhtml+xml" typed representation as an
      instruction to render the content of that representation according
      to the XHTML rendering model, including any subsidiary interactions
      (such as requests for external stylesheets or in-line images)
      called for by the representation.  In the scenario, the XHTML
      representation data received from the initial request instructs
      Nadia's browser to also retrieve and render in-line the weather
      maps, each identified by a URI and thus causing an additional
      retrieval action, resulting in additional representations that
      are processed by the browser according to their own data formats
      (e.g., "application/svg+xml" indicates the SVG data format), and
      this process continues until all of the data formats have been
      rendered.  The result of all of this processing, once the browser
      has reached an application steady-state that completes Nadia's
      initial requested action, is commonly referred to as a "Web page".


In summary, if we are going to describe the three architectural bases
of the Web in the introduction, then we should do it right.  Actually,
the current "Story" doesn't have any of these details within the
introduction, so the whole notion that it somehow "illustrates" them
seems a bit out of place.  I think it would be best to add a few more
details to the story to match the above paragraphs.

For the second edition, we desperately need additional story lines
that provide meaningful scenarios for the semantic web and web services.
It is near impossible to describe an architecture that is inclusive
of them without at least some use cases that are distinct from browsing.

Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>

Received on Saturday, 16 October 2004 06:30:57 UTC