From: Randy Trigg (trigg_at_parc.xerox.com)
Date: Wed 28 May 1997 - 13:29:44 CDT
_(fwd link)_>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
>How do people feel about this proposal? Does somebody have a scenario
>in which the link service itself _must_ be able to interpret a
_(fwd link)_I like the simplicity of your proposal, especially given how many complex issues are wrapped up in locSpecs ranging from search specs to anchor formats.
On the other hand, I'm concerned that your proposal will preclude _(fwd link)_interoperability between different HSs. At the very least we would need to name different locSpec templates (or "styles") and record the template name with the byte blocks on the server. Then those names would need to be understood by potential clients.
In the position statements at Southampton were several calls for an extensible standard for locSpecs. For example, see the Goose et al position statement where they call for locSpecs as an extensible set of typed fields. I think this also leaves open the possibility for locSpec interpretation on the server in cases where, say, link traversal or link filtering (ala Microcosm) needs to happen on the server.
So I guess I'm in favor of fleshing out a minimal agreed-upon form for storable locSpecs for the next version of the OHP.
This archive was generated by hypermail 2.1.5 : Tue 13 Aug 2002 - 07:20:35 CDT