Editorial comments on 28 Sep 2004 Editor's Draft of Web Arch

Hi TAG,

Here are some minor editorial comments on the 28 Sep 2004
draft. I relied heavily on the diff that Norm provided [1];
thanks Norm!

Good luck at the Basel meeting,

 _ Ian

[1] http://www.w3.org/2001/tag/2004/webarch-20040928/diff-20040816.html

----------------------------------------------------------

>2.1. Benefits of URIs
>
>  The choice of syntax for global identifiers is somewhat arbitrary; it
>  is their global scope which is important. The Uniform Resource

s/which/that

>  Identifier, URI], has been successfully deployed since the
>  creation of the Web. There are substantial benefits to participating
>  in the existing network of URIs, including linking, bookmarking,
>  caching, and indexing by search engines, and there are substantial
>  costs to creating a new identification system that has the same
>  properties as URIs.

The previous sentence doesn't really say why these are benefits.
For example, "linking" might be better explained as "the ability
to link to existing resources of value". Would it be useful to say
a bit more about each benefit?

[snip]

>2.2. URI/Resource Relationships

[snip]

>  [URI] is an agreement about how the Internet community allocates
>  names and associates them with the resources they identify. URIs are
>  divided into schemes and URI Scheme specifications define the
>  protocols by which scheme-specific URI are associated with resources
>  and take on meaning. 

I'm surprise that the word "meaning" has made its way back
into the document. [I wonder if Stuart saw this....]

>  For example, the HTTP URI scheme (RFC2616) uses
>  DNS so that names such as "http://example.com/somepath#someFrag" take
>  on meaning by way of HTTP GET response messages from the domain
holder
>  (or an agent they delegate to). HTTP GET is not the only way to
obtain
>  information about a resource. A third party, for example, might
>  publish a document that purports to define the meaning of a
particular
>  URI. 

I don't know what "meaning of a URI" means, and I thought we were
able to discuss the Web Architecture without using this sort of
phrase. The same comment applies to other uses of "meaning" in this
section.

[snip]

>2.2.1. URI allocation
>
>  To avoid URI collision (§2.2.2), it is important to avoid
>  assigning the same URI to different resources.

I still think that this section should define "URI collision"
before explaining why one should avoid it. Why not move
section 2.2.2 here?

In any case, the above sentence seems like a tautology since
"URI collision" is "assigning the same URI to different resources".

>2.2.1.1. URI ownership
>
>  URI ownership is a relation between a URI and a social entity, such
as
>  a person or an organisation. URI Ownership gives the relevant social
>  entity rights to:
>   1. pass on ownership of some or all owned URI to another owner--URI
>      allocation; and
>   2. to associate a resource with an owned URI--URI assignment.
>
>  By social convention, URI ownership delegated from the IANA URI
scheme
>  registry IANASchemes], itself a social entity, to IANA
>  registered URI scheme specifications.

I think this should be "IANA-registered".

>
>  Some URI scheme specifications further delegate ownership to
>  subordinate registries or to other nominated owners, who may further
>  delegate ownership. For example, the URN Syntax scheme RFC2141]
>  delegates ownership of portions of URN space to URN Namespace
>  specifications 

This is the first instance of ownership being delegated to a
specification. I would probably be useful to change

   "such as a person or an organisation" in 2.2.1.1 to 

   "such as a person, organization, or specification. In the case
    of a specification, ownership ultimately lies with the
    community that maintains the specification."

This will also
be helpful with respect to another proposed change below.

Also, please s/organisation/organization/g (and similarly for other
en-uk spellings).

> which themselves are registered in an IANA maintained
>  registry of URN Namespace Identifiers.

I think this should be "IANA-maintained".

>  Other URI schemes or nominated owners retain ownership within the
>  relevant scheme specification (or some other specification registered
>  in a subordinate registry) such that that specification and the
>  community that maintain it serve in the role of URI owners. 
>  For
>  example, the specification of the data URL scheme RFC2397]
>  serves as owner of all data scheme URI; it does not further delegate
>  ownership of portions of data URI space. It associates each data URI
>  with an resource, a representation of which is embedded with each
>  data URI (the representation is infact the resource).

The previous paragraph is _very_ hard to parse. I propose instead:

  Some URI scheme specifications do not provide for re-delegation of
  ownership. For example, the data URI scheme specification specifies
  that the resource identified by a data scheme URI has only one
  possible representation. The representation data makes up the URI
  that identifies that resource. Thus, the specification itself
  determines how data URIs are allocated; no re-delegation is
  possible. 

(Notice that I deleted uses of "URL"; not sure why it was used.)

>  URI Owners have a responsibility to avoid multiple URI assignments
>  that associate equivalent URI with multiple resources. 

I propose replacing the above sentence with the shorter:

   URI owners are responsible for avoiding the assignment of
   equivalent URIs to multiple resources.

> Thus, it is
>  also necessary that any approach to URI allocation, which passes
>  ownership of individual or organised sets of URI through
> delegation,
>  ensures that ultimate ownership of a particular URI is vested in a
>  single social entity (which may be a specification, a person or an
>  organization).

I don't think "it is also necessary" follows from what was stated
above. I propose the following piece of additional rationale:

  If a URI scheme specification does provide for the
  re-delegation of URI ownership, it should take pains to ensure
  that ownership ultimately resides in the hands of a single
  social entity. Allowing multiple owners increases the likelihood
  of URI collisions.

>  URI Owners may organise or deploy infrastruture to ensure that
>  representations of associated resources are available, and where
>  appropriate 

I think this should be "and, where appropriate, that"

> interaction with the resource is possible through the
>  exchange of representations.


>  There are social expectations for responsible representation
>  management (§3.6) [section 3.6] by URI owners, discussed below.
>  Additional social implications of URI ownership are not discussed
>  here. 


> However, the success or failure of these different approaches
>  depends on the extent to which there is consensus in the Internet
>  community on abiding by the defining specifications.

I think the previous sentence does not belong at the end of that
paragraph. It refers to "approaches". I think the approaches in
question are those related to name allocation, not those related
representation management. Therefore, I propose that the sentence
be moved to just after the sentence "By social convention,...".
>

[snip]


>2.2.3. Indirect Identification

[snip]

>  Suppose that nadia@example.com is Nadia's email address. The
>  organizers of a conference Nadia attends might use
>  "mailto:nadia@example.com" to refer indirectly to her (e.g., using
the
>  URI as a database key in their database of conference participants).
>  This doesn't introduce a URI collision.

s/doesn't/does not/

[snip]

>2.3.2. Representation reuse
>
>  Story
>
>  Dirk is editing a web page 

s/web/Web/g

>  and inserts a link to
>  "http://weather.example.com/2004/08/03/oaxaca" labeled 
>  `Current Oaxaca Weather Forecast'. 

I am confused by the above sentence. Does it mean the same as:

 "inserts a link labeled 'Current Oaxaca Weather Forecast' that
  has URI "http://weather.example.com/2004/08/03/oaxaca".

> Nadia spots the error 

That makes it sound like the error can be detected by looking
at the URI. See proposed replacement text below.

> and explains that the
>  resource Dirk has identified is the weather forecast for
>  03 August 2004. The URI for the current forecast is
>  "http://weather.example.com/oaxaca", even though that URI and the one
>  he used return the same representations today because it is the third
>  of August.
>
>  URI aliasing only occurs when more than one URI is used to identify
>  the same resource. The fact that different resources sometimes have
>  the same representation does not make the URIs for those resources
>  aliases. This occurs most commonly when a URI owner provides a URI
for
>  both the "current version" of something and a URI for the "version at
>  a point in time," as the Oaxaca weather Web site is doing, but it can
>  occur in other ways as well.
>
>  The distinguishing characteristic of representation reuse, as opposed
>  to aliasing, is that the underlying resources are different.

I propose the following replacement text for this section.

  <story>
  Dirk would like to add a link from his Web site to the Oaxaca
  weather site. He uses the URI http://weather.example.com/oaxaca
  and labels his link "weather in Oaxaca on 1 August 2004". Nadia
  points out to Dirk that he is setting improper expectations for
  the URI he has used. The Oaxaca weather site policy is that the
  URI in question identifies the current weather in Oaxaca -- on
  any given day -- and not the weather on 1 August. Of course,
  one day a year Dirk's link will be correct, but the rest of the
  time he will be misleading visitors to his Web site. Nadia
  points out to Dirk that the weather site does make available a
  different URI permanently assigned to a resource describing
  the weather on 1 August 2004.
  </story>

  In this story, there are two resources: "the current weather in
  Oaxaca" and "the weather in Oaxaca on 1 August 2004". The
  Oaxaca weather site assigns two URIs to these two different
  resources. On 1 August 2004, the representations for these
  resources may be identical. That fact that deferencing two
  different URIs produces identical representations does not
  imply that the two URIs are aliases. URI aliasing only occurs
  when more than one URI is used to identify the same resource.

[snip]

>3.2.1. Details of retrieving a representation

[snip]

>  Assuming that a representation has been successfully retrieved, the
>  expressive power of the representation's format will affect how
>  precisely the representation provider communicates resource state. If
>  the representation communicates the state of the resource
>  inaccurately, this inaccuracy or ambiguity may lead to URI
>  collision (§2.2.2). Efforts like the Semantic Web are seeking to
>  provide a framework for accurately communicating the semantics of a
>  resource in a machine readable way. Machine readable semantics may
>  alleviate some of the ambiguity associated with natural language
>  descriptions of resources.

The Semantic Web is not itself an effort. I suggest:

 "Some communities, such as the ones developing the Semantic Web,
  seek to provide a framework for accurately communicating the
  semantics of a resource in a machine readable way."

>3.6. Representation Management

[snip]

>  Just because representations are available does not mean that
>   it's

s/it's/it is

[snip]

>3.7. Supporting Navigation
>
>  It is a strength of Web Architecture that links can be made and
>  shared; once one user has found an interesting part of the Web, they
>  can share this experience just by republishing a URI.

Change "once one user has found an interesting part of the Web, 
        they can share this experience just by republishing a
        URI."

to 
       "a user who has found an interesting part of the Web
        can share this experience just by republishing a URI."


[snip]

>4. Data Formats
>
>  Data formats (for example, XHTML, RDF/XML, SMIL, XLink, CSS, and PNG)
>  are agreements on the correct interpretation of representation
>  data. 

I find the phrase "Data formats are agreements" jarring. How
about 

  "A data format specification (for example, for XHTML, RDF/XML,
   SMIL, XLink, CSS, and PNG) embodies an agreement on the correct
   interpretation of representation data."

[snip]

>4.2. Versioning and Extensibility

[snip]

>  In the real world, language designers imperfectly address the
>  requirements as they interpret them, the requirements inaccurately
>  model the world, conflicting requirements are presented, and they
>  change over time. As a result, designers negotiate with users, make
>  compromises, and often introduce extensibility mechanisms so
>  that it's

s/it's/it is/

>  possible to work around problems in the short term. In the long term,
>  they produce multiple versions of their languages, as the problem,
and
>  they're understanding of the problem, evolves. The resulting

s/they're/their/

>  variability in specifications languages, and implementations

missing a "," after "specifications".

[snip]

>4.2.3. Extensibility

[snip]

>  Extensibility introduces variability which has an impact on
>  interoperability. However, languages which have no
>  extensibility

s/which/that in the previous sentence.

>  mechanisms will be extended in ad hoc ways that impact
>  interoperability as well. One key criteria 

s/criteria/criterion/

> of the mechanisms provided
>  by language designers is that they allow the extended languages to
>  remain conformant, increasing the likelihood of
> interoperability.

I don't know what it means for an extended language to remain
conformant (to what?).

I propose instead:

  "One very useful characteristic of an extension mechanism is
  that it allow data conforming to an extended language to also
  conform to the original language, thus increasing the
  likelihood of interoperability."

[One might also talk about software conformance, but that's
included in the good practice note as it is written.]

[snip]

>8. Acknowledgments

We will add Noah to this list as well.

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