Re: RDF & fragment ids; what breaks?

On Thursday, Jan 23, 2003, at 09:43 US/Eastern, Mark Baker wrote:

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

It is not clear that visibility is worth the cost.
There is a value to information hiding, too.

There is a great power to be be able to make a new
language, and define a serialization for it, and define
a way of identifying some initialization parameter for whatever it is,
and to have the serialization in the web, and use the fragid
as the initialization parameter. For example, maybe I should
be able to talk about  main.c#foo
which is a application/c-source object where the
function foo is specified, maybe to be exectuted, (maybe to
be highlighted in the debugger).

This allows the new application to
spread across the web, and use all the existing proxies
and so on, without then having to know what goes on.

If you allow proxies to peek inside and understand what is going
on, sure they can do a better job, but you have to upgrade them all
when you introduce a new application.
This is the "smart network" model.

The Internet grew -- functionally -- because of its end to end
properties.   TCP does NOT look into the content of the stream.
Even though it could do a better job often if it did.

This (fragid hiding) is a form of end to end property.
The significance of the the mime message is known only
to sender/publisher and to receiver/browser.
It is only in that context that the fragment ID makes sense.

Yes, the idea of sending the fragment with a GET could get over problems
with content negotiation but it is probably the case that
if we started to let the fragid be seen all over the net,
then we would lose the ability to change what it meant in
a new application.

RDF uses this hook to introduce identifiers for arbitrary concepts.
I am inclined at the moment, rather than to make RDF look more
like HTML, to defend its right to be different.
And that's largely for data formats and languages to come,
and the *independent* evolution of existing ones.

Let nothing in TCP say what the TCP stream carries.
Let nothing in HTTP say what the fragid identifies.

Tim

> MB
> -- 
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
> Web architecture consulting, technical reports, evaluation & analysis

Received on Thursday, 23 January 2003 23:32:12 UTC