W3C home > Mailing lists > Public > public-webarch-comments@w3.org > October to December 2004

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

From: Norman Walsh <ndw@nwalsh.com>
Date: Wed, 13 Oct 2004 14:28:37 -0400
To: "Ian B. Jacobs" <ij@w3.org>
Cc: public-webarch-comments@w3.org
Message-id: <87zn2qmq0a.fsf@nwalsh.com>
/ "Ian B. Jacobs" <ij@w3.org> was heard to say:
|>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?

I think the reader will understand.

|>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.

This is text we agreed to in Ottawa, so I'm not sure I can remove it

Personally, I take "meaning" in this section to be used in a broad,
English-language sense, not in an RDF/semantic web sense.

|>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?

That looks like a good idea.

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

Yeah, that was a pretty poor sentence. I added it quickly to satisfy a
pedantic need to make sure that a section didn't start with a
subsection. I've improved it a bit, I think.

|> 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 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).

Uhm, yes. I fixed organization. I didn't notice the others :-/

|> 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. 

Yes, I think that's an editorial improvement. I changed
"re-delegation" to "delegation" as I didn't think the 're-' added

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

And I restored the URL (and the bibliographic reference). The title of
the RFC uses the term URL which is why I've used it:

  <p>Some URI scheme specifications do not provide for delegation of
  ownership. For example,
  the data URL <!-- sic --> scheme [<a href="#RFC2397">RFC2397</a>]
  specification specifies...


|>  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,...".

Actually, I moved it even farther up as I think it now fits in better
with the overall introduction to 2.2.2. I also think it may be a
vacuously true sentence that we could simply delete, but I haven't
done that :-)

| [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

Bleh. But, OK.

|>  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.

Much better. Thank you, Ian!

| [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

Uhm, ok.

| [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."


|>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."


|>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/

Why are we removing all the contractions?

|>  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".


|>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?).

To the original specification.

| 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.]

I think the QA folks want it worded more strongly than "a useful
characteristic", but I added "to the original specification" to the
sentence as I had written it.

|>8. Acknowledgments
| We will add Noah to this list as well.


                                        Be seeing you,

Norman Walsh <ndw@nwalsh.com> | Life does not cease to be funny when
http://nwalsh.com/            | people die anymore than it ceases to be
                              | serious when people laugh.--George
                              | Bernard Shaw

Received on Wednesday, 13 October 2004 18:28:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:47 UTC