Re: URIs / URLs

Joshua Allen <joshuaa@microsoft.com> wrote:

> Suppose I have a URL like:
> 
> hilite:808,30:http://www.netcrucible.com/semantic.html
> 
> which would browse to the specified document, scroll to the 808th
> character and highlight 30 characters in yellow.  This would be useful,
> right?  How many times have you wanted to be able to hyperlink to a
> *section* of document that doesn't have proper bookmarking?  But the
> problem is in trying to bootstrap this.

Well, this looks like a use case for XPointer or other kinds of fragment
identifiers. Since the Common User-Agent Problems (CUAP) document says that
the portion of a document identified by a fragment identifier should be
highlighted, and I believe XPointer allows you to specify character ranges,
this is already available, I think. (You'll have to check the relevant specs
to make sure.)

For this specific example, I think a new URI scheme would be an awful idea,
because you're not talking about a whole new class of resource -- instead
you're simply specifying certain portions of a current class. Furthermore,
URI schemes should specify resources, not how to display them or how to
treat them.

> On the other hand, if you did something like:
> http://www.hilite.com/hilite/808/30/www.netcrucible.com/semantic.html
> [...] The main draw here is that people could then begin using
> such transclusions in their pages without fear that they would be
> breaking 99% of the users, and users could get sucked into using this
> URL scheme without having to commit to using the plugin at first.
> 
> Well, I think this idea would really offend the purists, but there may
> be a more "pure" way to address these issues for someone developing a
> custom protocol handler framework...

I don't think it will offend the purists at all -- from everything I've
heard this is _exactly_ what the HTTP scheme is for, and the perfectly
correct way to bootstrap what might otherwise need new URI schemes. Adding
URI schemes is very expensive, since it affects just about _all_ systems
that use URIs, but using an older URI scheme has none of these problems. It
is often suggested that we need a new URI scheme for this or for that, when
HTTP URIs will do just fine.

As for writing browser plugins to deal with URIs, that's no problem either.
HTTP GET on the server itself is not the only way to resolve a URI --
browsers should be free to have numerous ways, making it easier and faster
to get information. This is to be encouraged, not afraid of.

So go ahead, use HTTP URIs to build test these new concepts! That's why
they're there!

-- 
[ Aaron Swartz | me@aaronsw.com | http://www.aaronsw.com ]

Received on Thursday, 12 April 2001 13:35:50 UTC