Client-side SELECTION; virtual anchors, colaborative hypermedia

I think I responded to the wrong question re: client-side highlighting.
Nevenmind.  My problem is client-side selection, not highlighting.

I do think it's important that we support virtual anchors addressed by
an object identifyer rather than a name.  Collaborative hypetext will require,
for example, that we select text and submit updates.  Named anchores should 
also be capable of addressing a personal or group proxy, e.g. 

<a name="theFollowingStuff" proxy="http://host.port/cgi/docMgr">stuff</a>.

Additionally, the client can route virtual and named anchor references 
through personal or group proxy servers to provide the functionality 
the user wants. (in the mean time all requests can be proxied to add
personalized functionality).  The client will need to create object identifier
anchor references for selections that are not named in the source, append
the identifier to the get, put, post, annotate, etc., and append the anchor 
reference to the url.  Some operations, such as PUT will require addition data 
to complete, but this will ultimately be the responsibility of the proxy, and
should not be implemented in the client unless the service (e.g. mail, news)
is also implimented in the client.

some/url#name  or some/url##<objectIdentifier> would provide an extensible
starting point and furtile soil for server developers of group hypermedia
support and other applications that can profit from user selected anchors.

A put operation, for example, may propose an edit that anchors existing
text to some href somewhere. The server authenticates the user, and files
the proposed update accordingly.  A personal proxy might indicate the users
proposed update on subsequent accesses to the document. A group proxy could
show the whole groups proposed links, etc.  The public proxy, named in the
actual body, p, or a tag, provies the public view of the documents evolution
and possible futures.  We may want a SELECT in HTTP distinct from GET
to present the user the menu of functionality supported by the page/anchor
via the various proxies (we'll need rules for well behaived value added
proxies).  Services that don't use the anchor part of the url, I expect, 
should ignore it.  An ADD-ANCHOR distict from PUT and LINK might be
desireable.

We don't want to provide dead end text without links, yet anchoring every
word does not work if the user wants to select a phrase.  The user selected
anchor/region provides a general solution independant of the particular
application, intuitive to users familiar with cut/copy/paste type functionality.

Increasingly we are encoding semantic information in HTML coding of documents.
User selected anchors provide a means for application developers to capture,
manupulate, and utilize such information.  Thw WEB is NOT static documents,
it is a dynamic network of information.  We need ubiquitious clients with
the power to address html segments and maniputate them in an object
oriented manner.  What I'm suggesting is a start in that direction, so
service developers can run amuck and build the knowledge bases of 
tomorrow.

Jim Whitescarver. jim@njit.edu

Received on Wednesday, 15 March 1995 12:33:40 UTC