Tue, May 23, 2006
URI Syntax for the HyperScope
#
At last Tuesday's HyperScope meeting, JonathanCheyer and I spent an
inordinate amount of time debating the syntax for HyperScope URIs,
much to the amusement and chagrin of our peers. Although the topic may
seem insignificant, it is actually quite layered with no easy
answers. I'm going to summarize the issues here. Most of you will
probably not care about the intricacies of the argument itself, but at
minimum, it should reveal a bit more about the project itself. (KI2)
HyperScope is meant to be a transitional tool that will enable people
to play with Augment's more sophisticated capabilities within
their existing environments. In the immediate future, that means the
FireFox web browser (and probably InternetExplorer as well). In the
not-to-distant future, that could extend to a range of applications,
from Eclipse to OpenOffice and beyond. (KI3)
This intent strongly informs our requirements. In particular, we
need to make sure we are bootstrapping the system on top of existing
technologies (such as URIs) effectively and correctly, and we need to
make sure the system is evolvable. Both of these requirements play a
big role in our debate. (KI4)
So what's all the fuss about? One of Augment's coolest (and most
fundamental) features is its sophisticated addressability. The example
most folks know about manifests itself as PurpleNumbers, namely the
ability to reference a specific node in a document in a standard way.
But Augment can do much, much more. It can do path expressions,
similar in spirit to XPath, which allows you to reference some subset
of nodes in a document. (See my
notes on transcluding a subset of nodes via PurpleNumbers). (KI5)
You can also embed ViewSpecs in an address. For example, suppose you
decided that the best way to view a page was the first level of nodes
only. You could specify that as a ViewSpec in the link itself, so that
when someone followed that link, they would see only the first level
of nodes rather than the entire document. (KI6)
With the HyperScope, we're bringing these capabilities to the plain
ol' World Wide Web -- that is, assuming your client knows how to
interpret these addresses properly. With our initial release (due
September 2006), this will require loading a JavaScript library. All
document addressability will happen entirely on the client-side. This
is a good thing for a lot of reasons, the most important being
adoptability. It will be easy for people to play with the
HyperScope. All they'll have to do is click on a link in FireFox (and
probably InternetExplorer). (KI7)
However, the fact that we're doing a client-side only version of the
HyperScope does not preclude the creation of a joint client/server
version or even a mostly server-side version where the client is
essentially a dumb web browser. In fact, we'd encourage the creation
of both. We don't care some much about implementation as we do
capabilities and interoperability. (KI8)
Here's the question: How should we include these extended addressing
capabilities in real-life URIs? (KI9)
There are three possible solutions: (KIA)
- Embed them as a fragment address (i.e. following a hash mark at the
end of the URI). (KIB)
- Embed them either as part of the path or query string
parameters (i.e. following a question mark at the end of the URI). (KIC)
- All of the above and more. (KID)
I side with the first and third solutions. Jonathan thinks it should
be the second. (KIE)
Fragment Address (KIF)
Pros: (KIG)
- These extended capabilities seem to belong here
semantically. PurpleNumbers are an obvious example of this.
XPointer is another. (KIH)
- The URIs will be bookmarkable as the user manipulates the document
from the HyperScope. We can do this, because we can change the
fragment identifier from within JavaScript. We can't do the same
with any other part of the URI. (KII)
Cons: (KIJ)
- These URIs cannot be used for a server-side only solution, because
HTTP does not pass the fragment identifier to web servers. (KIK)
Path or Query String (KIL)
Pros: (KIM)
- Can be used for client-only or server-only solutions, or anywhere in
between. (KIN)
Cons: (KIO)
- You're still left with the problem of a standard addressing syntax
that doesn't interfere with any other kind of addressing. For
example, if you're going to use a query parameter, what do you call
it? Granted, if you namespace it correctly, the likelihood of
namespace clash is tiny, but it's still there. (KIP)
- No one's building a server-side only solution right now. (KIQ)
Why Limit Yourself? (KIR)
This is ultimately my argument: Go with the first syntax for now,
because it best suits our current needs, and don't worry about the
fact that it won't satisfy all potential future needs, because nothing
will. What's important is that we standardize the conceptual
semantics, and then standardize the syntax to the extent possible. In
all likelihood, most people will be passing these links around by
copying and pasting them anyway, so the actual link syntax isn't
completely critical. (KIS)
/tech/hyperscope |
Posted at 4:40pm
Comments
Comments disabled until future notice. If you'd like to contact me, use my i-name (=eekim).