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

Arch Doc: 26 September 2003 Editor's Draft

From: Ian B. Jacobs <ij@w3.org>
Date: 26 Sep 2003 16:05:24 -0400
To: www-tag@w3.org
Message-Id: <1064606723.1372.15.camel@seabright>

The 18 September 2003 Editor's Draft of "Architecture of
the World Wide Web" is now available at:


Please note in particular the change to the abstract,
based on Roy's recent proposal and subsequent discussion
on the list.

Complete list of changes:

HTML diff:

Below is the list of comments I did not take into account
for this draft; I anticipate that the TAG will provide
direction at the 29 Sep teleconference.

Thank you,

 _ Ian


Comments from Stuart

1) SW: Likes Roy's intro text. However, previous comments from
   DC and TB point to issues they have with that text (e.g.,
   not confined to spanning Internet, not limited to sources
   and services, etc.).


See abstract proposed in 26 Sep draft.

2) Endnote 2 requires clarification. This is based on text
   from Roy.

    "User agent configurations are usually defined by URI scheme,
    with exceptions defined by further substring matches within
    the URI."


3) Endnote three and use of other protocols than HTTP for
   http URIs. Reference RFC 2396, section 1.2:

    "Although many URL schemes are named after protocols, this
    does not imply that the only way to access the URL's resource
    is via the named protocol.  Gateways, proxies, caches, and
    name resolution services might be used to access some
    resources, independent of the protocol of their origin, and
    the resolution of some URL may require the use of more than
    one protocol (e.g., both DNS and HTTP are typically used to
    access an "http" URL's resource when it can't be found in a
    local cache)."

Proposal: Added reference.

4) Cause/effect backwards in describing "link".

   I must be missing a subtle point. I don't know how (in the
   Web arch) to detect that two resources are linked until
   a URI ref appears in a representation.

5) 2.4.1 Secondary Resources...

  SW: "Knowledge of the media-type associated with a frag-id is
  implicit in the account given here. This seems to be at odds
  with the use of URI references as opaque identifiers as
  typified in RDF/Semantic Web. ie. we only give an account here
  of the use of fragment ids in relation to a representation with
  a known media-type"

  IJ: Does the following sentence which appears in the next
      paragraph suffice?

    "The presence of a fragment identifier agent in a URI does
    not imply that a retrieval action will take place."

  Or, from [URI]:

    "As with any URI, use of a fragment identifier component does
    not imply that a retrieval action will take place. A URI with
    a fragment identifier may be used to refer to the secondary
    resource without any implication that the primary resource is
    accessible. However, if that URI is used in a context that
    does call for retrieval and is not a same-document reference
    (section 4.4), the fragment identifier is only valid as a
    reference if a retrieval action on the primary resource
    succeeds and results in a representation for which the
    fragment identifier is meaningful."

6) "For schemes that do specify the use of fragment identifiers..."

   SW: "It is not within the gift of a URI scheme to specify the
   use/non-use of fragment identifiers. They are a part of the
   generic URI syntax, and definition of the frag-id 'semantics'
   is delegated to media-type specifications, not URI scheme

   IJ: I looked at a number of the URI scheme specs to see if
   I could find any examples of a scheme spec talking about
   whether frag ids are actually used in URIs for that scheme
   (e.g., mailto). I found no such statements, so I am deleting
   the sentence in question.

   See also comments from TB about use of URI scheme spec
   (comment 33 in 

7) Good Practice Note: Content Negotiation With Fragments.

   SW: I prefer the wording of the Good practice note "Content
   negotiation with fragments" from the current TR page draft:

8) 2.5.2

   SW: Step 5&6 refer to "Content-type field": s/field/header/

   Looking at RFC2616, I find, for example in 9.2:

     "If the OPTIONS request includes an entity-body (as
     indicated by the presence of Content-Length or
     Transfer-Encoding), then the media type MUST be indicated by
     a Content-Type field."

  No change.

9) 2.6 Persistence and Ambiguity

  No text proposed; no change.

10) 4.5 Binary and Textual Data Formats

  SW: "I wonder if some of the current discussion re text/*+xml
  and application/*+xml should be reflected here. The bias in 4.5
  is to promote XML as textual data format, so perhaps some
  careful words are in order around the TAG disposition wrt
  text/*+xml. Maybe a forward reference to 4.10.6 would cover
  some of this."

  There is a forward ref in first sentence. Not sure what else
  to add before more discussion in TAG.

Comments from Norm	

11) Present table of notes after TOC as three lists.

12) Choose a different icon (smaller) to indicate story.
    Roy seems to concur.

13) 1.1 feels out of place.

14) Section 2.4.1, fourth bullet of first bulleted list:

   NW: s/is "U#fragid"./is "U#fragid" when the resource retrieved
                        is in format "F"./

   IJ: I don't see why retrieval is required.

15) 2.5.2

   NW: Delete "Remember that search engines may follow such links."

   IJ: I think this reminder is helpful.

Comments from Norm	

16) Section 2.6:

   a) Doesn't like ambiguity example; too linked to httpRange-14.
   b) Moby Dick example unclear, "beached".

Comments from David

17) Definitions of terms and diagram illustrating their

    IJ: I would like to have a series of diagrams that progress
    from simple to more complete. I am not sure that all relationships
    should appear in the same diagram.

Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447

Received on Friday, 26 September 2003 16:05:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:01 UTC