Re: Another day, another idea: generic handling of fragment identifiers

Larry Masinter <masinter@parc.xerox.com> writes:
> Right now, #fragment identifiers are only interpreted
> for URLs that resolve to text/html. I'd like to push
> forward to define some interpretation for fragment
> identifiers for other media types.

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	<burchard@cs.princeton.edu>
``I'm still learning how to count backwards from infinity...''
--------------------------------------------------------------------

Received on Friday, 1 September 1995 06:40:29 UTC