RE: [Publication] 29 Oct 2002 Arch Doc

Hi Ian,

Thanks for responding to my comments. I have some responses to the questions
you ask below, but the short answer is that I can live with things for as
they are in the 12 Nov draft for this round of publication.

Cheers,

Stuart
--

> -----Original Message-----
> From: Ian B. Jacobs [mailto:ij@w3.org]
> Sent: 12 November 2002 22:37
> To: Williams, Stuart
> Cc: www-tag@w3.org
> Subject: 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.

I think we resolved both of theses :-)

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

<snip/>

> > 1.3 Summary of...
> > -----------------

<snip/>

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

Seems about right... maybe b) is more that "Ambiguity arises when names are
used in the absence of some neccessary context".

<snip/>

> 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

I think thats fine for now... but I don't think that we're done with this
topic :-).

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

Well yes, but it also seems like common sense, so its useful that 2396 does
have something to say.

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

I reading the last clause as saying that when a "...URI refererence is
intended for retrieval and the result of that retrieval [which I take to be
a representation] is a document [representation sense of document rather
than resource sense of document] for which the identified fragment is
consistently defined [the referenced fragment is a representation of a
consistent part of the resource independent of which particular
representation is retrieved]."

Of course I may be reading too much into that one clause... and the initial
'intended for retrival' qualifier means that nothing is said about URI
references that are not intended for retrival.

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

Ok, I'll try. Imagine a resource describes a car (a document that describes
a car). Imagine that there are both XHTML and SVG representations available,
and that within each of these there was a fragment of the representation
that represented the engine (narrative engine spec in XHTML, annotated
schematic in SVG). Sticking an ID of 'engine' on the relevant element in
each representation would enable consistent references to be made to the
#engine fragment. However, a fragment identifier that 'navigated' the
document structure to the same (engine) element in one representation would
be very unlikely to identify the corresponding part of the another
representation of the same resource (unless you are very lucky).

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

<snip/>

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

I think this is more correct if by connection it is meaning the physical
connection to the telephone network. 'Describes' is a little vague!

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

'Describing' again!

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

It will do for now, thanks. Don't really want to make a 'rathole' out of it,
more that I think we need to be fairly precise if we are saying things like
tel: URI identify telephones - well in a temporal context and with transfers
of meaning perhaps they do, but in an absolute single context or
context-free world... I think it's harder to make that assertion stick.

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

Ok.

<snip/>

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

Actually I think I'd be inclined maybe to go the other way and speak of "Use
of URI", 1) "As Identifiers" and 2) "For interacting with resources".

1) then leads to the need to compare URI while 2) leads to an operational
need for a process to map from URI to means of interaction with a resource.

<snip/>

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

Firstly, we don't have to settle this for this round of publication...

I think we'd agree that 2396 is the 'contract' (maybe) and the use of URI in
some sense represents *agreement* to that contract. The maybe is because
2396 is primarily about the generic syntac of URI References rather than
assignment policies for names - which I suppose it delegates to the relevant
URI scheme registrations.

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

Unfortunately not... I stick with what we have for now...

2396 and related materials (URI scheme defns) describe the semantics of a
URI in a very operational sense (there are probably exceptions) along the
lines of "that which results when you do these things." Some specs are
beginning to use URI to identify concepts and those specs would (I expect)
say what some particular URI means in a more denotational style - this URI
denotes this concept. 

<snip/>

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

Will live with for now, particularly if it is to disappear anyway. 

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

<snip/>

Received on Wednesday, 13 November 2002 07:12:23 UTC