Re: [Publication] 29 Oct 2002 Arch Doc

Williams, Stuart wrote:
> Ian,
> 
> Detailed comments below. Of these, the ones related to URI terminology
> (request a commitment to being aligned with a successor to 2396) and URN
> Namespaces, should be addressed before we publish a new WD. Easy editorials
> should be done. More philosophical points can be resolved later.

Thanks for the comments, Stuart. I will include some changes in the
next draft. See comments below.

  - Ian

> Introduction:
> -------------
> I like the Identification, Representation and Interaction split. One of the
> things Roy has also spoken about, at least in conversation, is application
> state. I'm tempted to suggest that the third component be "Interaction and
> Application State" - just a thought!

Since section three is still quite undeveloped, I'd prefer to hold
off on this change until we have more text for the section.

> 1.1 Audience
> ------------
> References RFC2026 for process that the IETF follow. I think it might be
> better to reference the RFC Index for more information on RFCs rather that
> the process that creates them. Alternatively, it might be better to identify
> particular RFCs of import (2396, 2616,...)

Yes.

> 1.3 Summary of...
> -----------------
> a) Consistent URI: "Indiscriminate use of a URI..." doesn't really
> communicate what this one is about. "Inconsistent use of a URI undermines
> its value to the systems (and people) that use it. Within a given context a
> URI is expected to consistently identify the same resource."
> 
> [This latter acknowledges the possibility of multiple contexts, and that the
> 'meaning' of a URI is/should be unambiguous within some context of use...
> but may be different in different contexts. Larry Masinter has been making
> this point (I think) with reference to a paper on "Transfers of Meaning"
> [1]. This might be objectionable if you regard the URI->Resource mapping as
> context-free.]

Sections 2.2.4 and 2.2.5 of the 7 Nov draft [1] present a model
where there is an authoritative meaning, and it is context-free: the 
authoritative meaning is determined by following specifications.

URIs nonetheless take on meaning of their own through usage. When 
this usage is inconsistent with the authoritative meaning, that 
undermines the value of the URI.

There seem to be two schools of thought on this matter, which
I would paraphrase imperfectly as:

   a) Follow specs. Ambiguity is a bug, not Web architecture.
   b) Ambiguity arises in any use of names.

Right now I am trying to make the document say:

   a) Authoritative meaning is derived by following specs.
      Representations should be used to explain the meaning
      of a resource.
   b) People may not be able to encode all of their knowledge
      perfectly in a representation, so some ambiguity is
      likely to crop up. Descriptions of a resource
      should endeavor to reduce ambiguity (they shouldn't
      change radically, they should not be vague, they should
      be available in the first place, etc.).
   c) People should use URIs in a way that is consistent with the
      authoritative meaning. If they don't, then the value of
      those URIs decreases.

Therefore, I would prefer not to include more information
about context-sensitive interpretations of URIs.

[1] http://www.w3.org/2001/tag/2002/WD-webarch-20021107

> b) Coneg with fragments: I think this one is difficult to express. I think I
> would prefer a SHOULD rather than a SHOULD NOT, and suggest "When
> representations of a resource are available in multiple formats, fragment
> identifiers in resource references SHOULD be used in a way that identifies a
> consistent part of a representation."

In the 7 Nov draft, this good practice note reads:

   "Authors SHOULD NOT use HTTP content negotiation for different
    media types that do not share the same fragment identifier
    semantics."

This not refers to consistency among media type semantics. Your 
proposed text refers to consistency among parts of a representation.
I believe you are trying to stick closely to RFC2396, but I confess
I have trouble understanding what "is consistently defined" means
in the following paragraph. It refers to a single representation
(document) rather than a series (across which the fragment could
be used consistently).

Thus, I seek clarification of the meaning of "in a way
that identifies a consistent part of a representation."

> Last paragraph of section 4.1 in RFC2396 says (trailing clause):
>    A fragment identifier is only meaningful when a URI reference is
>    intended for retrieval and the result of that retrieval is a document
>    for which the identified fragment is consistently defined.

> 
> 2 Identification and resources
> ------------------------------
> Editorial:
> "Several URI schemes incorporate into this syntax some identification
> mechanisms that pre-date the Web"
> 
> Reword as: "Several URI scheme incorporate identification mechanisms that
> pre-date the Web into this (generic URI) syntax."

Yes (with an "s" after "scheme").

> Picky:
> TEL URIs identify telephones? I don't think so... they might identify a
> collection of telephone connection endpoints (wall sockets), but even then
> those are easily associated with a different telephone number (office moves,
> house moves, telephone number changes).

Section 1.1 of RFC2806 [2] states:

    'The "tel" scheme describes a connection to a terminal that
    handles normal voice telephone calls, a voice mailbox or another
    voice  messaging system or a service that can be operated using
    DTMF tones.'

However, earlier we find:

    'This specification defines three new URL schemes: "tel", "fax"
    and "modem". They are intended for describing a terminal that can
    be contacted using the telephone network.'

In the interest of brevity, how about stating in the arch
doc that "TEL URIs identify terminals on the telephone network"?

I'll also update the "news:" description to refer to USENET news 
groups (per RFC1738).

[2] http://www.ietf.org/rfc/rfc2806.txt

> Last paragraph on URI terminology difference. I would like to see a
> commitment on the part of W3C/TAG to use terminology that is consistent with
> any updates to 2396. It's fine if the process of updating 2396 results in an
> agreed change in the use of terms. IMO it would not be fine for our work and
> the successor to RFC 2396 to use the same terms with subtle differences in
> meaning. 

Per discussion at the 11 Nov TAG teleconf [3], there is agreement 
that terminology should be harmonized, but not agreement that we 
should commit to a future 2396 without having seen it.

[3] http://www.w3.org/2002/11/11-tag-summary#archdoc

> 2.1 Resources, URIs and shared information space
> ------------------------------------------------
> Uses the term 'addressable' repeatedly throughout. We speak of 'identifiers'
> and 'references', of 'retrievability' and 'dereference'. Do we really need
> the word 'addressable'?

I will change "address" (and its variants) to "identify", except in
the titles of references.

> 2.2 Operations on URI
> ---------------------
> 
> "2 Interaction with resources". Not sure that this really counts as
> Operations on URI. It is certainly a use of URI. I think the operation on
> the URI in such circumstances is 'dereference' effectively maps from the URI
> to the referenced resource.

Ok. In section 2.2.2 of the 7 Nov draft, we find:

   "To dereference a URI is to interact with the resource it
    identifies."

So I can move the dereference up to bullet 2.

> 2.2.1 Comparison of Identifiers
> -------------------------------
> Repeated avoidance of using the terms "URN Namespace" and URN Namespace
> Identifier (NID)". I would prefer to see the URN RFC properly referenced and
> the terms defined therein used properly.

Ok. I will use "namespace identifier" instead of "subclass", and
delete the endnote.

> 2.2.2 Interactions with resources
> ---------------------------------
> Firstly this might belong in the section on Interaction.
> 
> "To dereference a URI is to interact with the resource it identifies."
> Hmmmm.... I think interaction involves dereference, but dereference is to
> (repeatedly if necessary) resolve a URI into a set of communication
> parameters (access protocol, host addresses, port numbers...) as a precursor
> to interaction. Conceptually it is moving from one end of a pointer (the
> referencing end) to the referenced resource.

I will merge two sentences in this section into one, which I think
captures what you are saying.

> 2.2.4 Consistent representations and persistence
> -------------------------------------------------
> "URI's represent as worldwide contract..." RFC2396 *might* represent such a
> contract, but I don't think URIs do in and of themselves. I'm also not sure
> URIs or RFC2396 say (or could be expected to say) how resources designated
> by URI take on meaning. 

I don't think the sentence is that far off. One might say
that RFC2396 *is* the contract. Therefore, URIs represent
that contract.

As to whether RFC2396 says how resources take on meaning,
I don't see where it does. Can you suggest alternative text?

> 2.2.5 (See earlier comment on Inconsistent use of URI)
> ------------------------------------------------------
> 
> 2.3 URI Schemes
> ----------------
> Last sentence end "URN subclasses". Please use URN terminology... ie URN
> Namespaces.

Yes.

> 2.5 Some Generalities...
> ------------------------
> "Some of these generalities do not hold..." seems a bit of an oxymoron. If
> they don't generally hold, they are not generalities and should not be in
> the list.

Changed to "These are generalities because they hold for some,
but not necessarily all, URI schemes."

> The list probably needs to be crisper (less fluff).

I am hoping that the list will disappear as we improve the document.
I've already been able to delete one of them since it's been used
earlier.


>>-----Original Message-----
>>From: Ian B. Jacobs [mailto:ij@w3.org]
>>Sent: 30 October 2002 00:13
>>To: www-tag@w3.org
>>Subject: [Publication] 29 Oct 2002 Arch Doc
>>
>>
>>
>>Hello,
>>
>>I've made available the 29 Oct 2002 Architecture Document [1].
>>This draft incorporates reviewers' comments and TAG
>>discussion of those comments since the TAG's Sep 2002
>>face-to-face meeting.
>>
>>This draft does not include substantial amounts of new
>>text. However, there are some new notes in section 3
>>(formats). I anticipate a new draft in the next week
>>that will include new text from TAG participants.
>>
>>The list of changes [2] is available.
>>
>>  - Ian
>>
>>[1] http://www.w3.org/2001/tag/2002/WD-webarch-20021029
>>[2] http://www.w3.org/2001/tag/webarch/changes#changes-20021029
>>
>>-- 
>>Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
>>Tel:                     +1 718 260-9447
>>
> 
> 


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

Received on Tuesday, 12 November 2002 17:36:43 UTC