Re: opaque locspecs

From: Kenneth M. Anderson (
Date: Thu 24 Apr 1997 - 00:02:30 CDT


Peter J. Nuernberg ( on 4/17/97 7:35 AM wrote:

>I propose that the OHP treat locspecs as opaque byte blocks. If we
>wish to have additional (optional) standards that define the structure
>of locspecs, to which application and/or behavior developers wish to
>subscribe, this seems like a fine idea as well. Maybe we can add some
>"suggested" locspec formats (like Sigi's format) as an appendix to the
>OHP document.
>How do people feel about this proposal?

I just wanted to respond to Peter's posting and say that I must agree with this proposal. This isn't all that surprising or difficult for me to agree to however since it matches the way we already do things in Chimera. Chimera doesn't have an official concept named "locspec" but Chimera clients make use of an attribute-value mechanism to store their "locspec"-like information with Chimera anchors.

In the OHP spec (, there is a discussion on the way anchors are handled in most systems:

"Different systems allocate anchors in different ways. There are four principle methods:

   1.The application embeds the anchor in the node data. In this case the application may also embed all the link information at this point (e.g. URL's embedded in html as HREF's) or might allocate an ID to the anchor which is unique to this node, and which will specify to the link service the link or links in which the anchor participates, as in Hyper-G (Andrews et al., 1995).

   2.The application allocates an ID for the anchor, which will be unique for that node, and takes responsibility for maintaining a table of IDs and LocSpecs belonging to the node. The link service can resolve an anchor by using the (node name, anchor ID) pair. This is the approach taken by most Dexter based systems such as DHM.

   3.The application requests that the link service allocates an ID for the anchor, which will be unique over the entire link service. The application will still need to maintain a table of anchor IDs and LocSpecs at run time. This approach is taken by Multicard and the hyperbase class of systems.

   4.The application talks to the link service by transmitting the node identifier and LocSpec, and allocates no specific anchor ID at all. This is the approach taken by Microcosm."

Chimera's mechanism is thus a variation on number 3. Clients ask Chimera to allocate a link-service-wide unique id for an anchor. Clients then have the option of associating locspec-like information with the anchor id using attribute-value pairs or maintaining a table of anchor ID/locSpecs themselves. Almost all Chimera clients take the former approach.

The protocol appears to have taken an approach to accommodate all four styles listed above. In fact it was this flexibility which convinced me not to raise this issue (opaque locSpecs) in my workshop submission, since I could see a way to map from the OHP spec into the Chimera handles anchors. As defined, I would have had to include a locSpec parser in my "shim" but then I would be free to ignore the parsed locSpecs within Chimera. Peter's proposal simply makes it easier for me to ignore the passed locSpec!

>From my brief overview of the anchor related operations of the OHP, it
appears that the only change required to accommodate Peter's request is to associate a length parameter with locSpecs which specifies the length in bytes of the locSpec. Open Hypermedia systems that wanted to treat the locspecs as opaque would then be able to do so by simply passing them around as byte streams. OHSs which depend on locspec contents (i.e. approach 4 above) would still be able to interpret the locSpecs as usual and would be burdened with only a small additional amount of work (i.e. generating the length of the locSpec in bytes).

So, I second Peter's proposal and look forward to additional comments on this issue.


Kenneth M. Anderson               | Read books by Stephen R. Donaldson
Graduate Student                  | <>
_(fwd link)_University of California, Irvine  | <>

This archive was generated by hypermail 2.1.5 : Tue 13 Aug 2002 - 07:20:34 CDT