W3C home > Mailing lists > Public > public-bpwg@w3.org > August 2008

Re: ACTION-703 ISSUE-222 Draft text: On Linking Alternative Representations To Enable Discovery And Publishing

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Tue, 05 Aug 2008 19:54:17 +0200
To: Jo Rabin <jrabin@mtld.mobi>
Cc: Francois Daoust <fd@w3.org>, MWI BPWG Public <public-bpwg@w3.org>
Message-Id: <1217958857.6519.63.camel@localhost>

Le mardi 05 août 2008 à 18:22 +0100, Jo Rabin a écrit :
> > RFC 3986 makes it clear that same-document references are references to 
> > the current representation of a resource and not the resource itself:
> > http://www.rfc.net/rfc3986.html#s4.4.
> > 
> Well, I thought we had that discussion at the F2F and I thought Dom had 
> a brilliant reason for discarding it. I remember successively trying 3 
> different ideas till one got the Dominesque nod. And I thought one of 
> them was specifically this. I will check the minutes out and see if my 
> memory is at fault and find the reason that an empty reference did not 
> meet with approval.

My reasoning was that given a URI U, the empty reference given in a
representation R of U by default would point to U rather than
specifically to R.

But the URI spec seems to say otherwise (as Francois noted above) - so
apparently, my reason for discarding it was not only not brillant but
also false :) :
        When a URI reference refers to a URI that is, aside from its
        fragment component (if any), identical to the base URI (Section
        5.1), that reference is called a "same-document" reference.
        [...] When a same-document reference is dereferenced for a
        retrieval  action, the target of that reference is defined to be
        within the same entity (representation, document, or message) as
        the reference;

I expect we will recognize that as part of our LC processing, but in the
mean time, it may be just as well to amend our message to the TAG
accordingly - unless you disagree, obviously.

Dom
Received on Tuesday, 5 August 2008 17:55:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:08:57 UTC