W3C home > Mailing lists > Public > www-tag@w3.org > January 2003

Re: RDF & fragment ids; what breaks?

From: Mark Baker <distobj@acm.org>
Date: Thu, 23 Jan 2003 09:43:09 -0500
To: Miles Sabin <miles@milessabin.com>
Cc: www-tag@w3.org
Message-ID: <20030123094308.E19606@www.markbaker.ca>

On Thu, Jan 23, 2003 at 08:51:30AM +0000, Miles Sabin wrote:
> In the context of my reply to Tim Bray's mail, I think "break" is 
> exactly the right word.

Sorry, I just meant *I* wouldn't use that word.

> > It would certainly reduce visibility into the message by HTTP
> > components that relied on the assumption that the URI in the HTTP
> > request line identified the resource being interacted with.
> I don't believe it would.

If an HTTP client is told that "http://example.org/foo#bar" identifies
a resource of interest to it, and attempts to dereference that URIref,
"#bar" isn't part of that HTTP GET message that gets sent.  By
*definition*, other HTTP components have less visibility into the
meaning of the message than the client.

> But it's absolutely not legitimate to insist that that mindset or 
> methodology is the only way of obtaining that useful property, or to 
> insist that it's privileged to the exclusion of all else. That _does_ 
> break things (in this case RDF), at least politically, by effectively 
> ruling out other equally useful approaches.

As I see it, in order to recover this lost visibility, one of two things
would need to occur.  Either RDF/SW have to start identifying things
without fragment ids, or we need to deploy some means of introducing the
fragment id into the HTTP message envelope (Request-URI -> Request-URIref,
an extension header, etc..).  As Tim Bray correctly (IMO) pointed out,
it's a whole lot easier to do the former than the latter at this point
in time.

Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis
Received on Thursday, 23 January 2003 09:41:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:57 UTC