This is really important, and ties in with the cid:/data: issue as
well as interactivity. Some thoughts:
1. To clarify their new, more general roles, I'd like to call
"#fragment" stuff the "client-side specializer", and "?query" stuff
the "server-side specializer". The URI standards need to be firmed
up on the point that such semantic separation be scheme-independent.
2. Client-side specializers are important for interactivity.
Scripting media are usually initialized with client-side parameters
in order to increase reusability, and these initializers may be
large. (Here and in the next item I'm indebted to some earlier
observations by Gavin Nicol.) So I'd add application/java and
application/python to the list of eligible media types.
3. As has long been evident for query strings, both server- and
client-side specializers may become large, and have their own
internal structure. That is, they are analogous to your data: URIs
that stick a small object right in the URI. The Web's link model,
however, should have general support for indirect access to larger
specializers through URIs of their own.
In other words, these specializers are essentially client- and
server-side "typed arguments" to Web resources. In particular, I
would say that formally, client-side specialization is a polymorphic
function of _two_ MIME types. To put it in C++-ish language, the
specification of MIME types would be allowed to overload "view"
methods as follows:
class media1 {
view(void); // standard display
view(media2 frag); // specialized by media2
view(media3 range); // specialized by media3
};
In the same way, each addressing scheme would be responsible for
handling different server-side types:
class scheme1 {
object get(uri addr); // standard retrieval
object get(uri addr, media1 query); // specialized by media1
object get(uri addr, media2 query); // specialized by media2
};
To show how all this would work concretely, consider first the
implementation of the link model in HTML. We would define uniform
attributes (say) QUERYREF and FRAGREF for all hyperlinking elements.
Their typical use would look like:
<A HREF="http://server/scriptgenerator"
QUERYREF="cid:queryparams"
FRAGREF="cid:initparams">
Here, if cid:queryparams is a text/plain object containing
"qqqqqqq", and cid:initparams is a text/plain object containing
"iiiiiiii", then the above is defined to be equivalent to:
<A HREF="http://server/scriptgenerator?qqqqqqq#iiiiiiii">
or, in a frivolous use of Larry Masinter's data: idea, also
equivalent to:
<A HREF="http://server/scriptgenerator"
QUERYREF="data:text/plain;;qqqqqqq"
FRAGREF="data:text/plain;;iiiiiiii">
On the server side, consider the HTTP addressing scheme as in the
above example. If our cid:queryparams had a text/plain media type,
an ordinary GET query transaction would be made. However, if
cid:queryparams had a media type other than text/plain, the link
would generate a GET transaction with a body part equal to the
object referenced by cid:queryparams.
P.S. There are other addressing problems that need to be solved for
an interactive Web, but this is a start.
--------------------------------------------------------------------
Paul Burchard <[email protected]>
``I'm still learning how to count backwards from infinity...''
--------------------------------------------------------------------