From: Peter J. Nuernberg (pnuern)
Date: Thu 17 Apr 1997 - 09:34:21 CDT
The original protocol paper  decsribed locspecs as having a mime type, content, a count and a reverse count, a name, and a script. Sigi's position paper  at OHS3 expanded upon this by adding notions of a location type (NameLoc, CoordLoc, etc.)
I would like to propose that there are two separate issues involved
here. At the level of applications, we should try to consider
"standardizing" certain locspec representations. If two people both
develop text editors, they can try to build locspecs in such a way as to be able to understand one anothers locspecs. This will allow each editor to display locspecs built in the other editor. This has nice advantages.
However, from the point of view of the link service, it should be completely irrelevant what the structure of these locspecs is (if any). The OHP need only traffic in arbitrary byte blocks for locspecs, with the only semantics assigned to locspecs being that they specify a location.
It may be true that certain processing apart from the client may want to interpret locspecs as well. In the SP/HB and HOSS terminology, behaviors may want to interpret locspecs. While this may be true, it does not seem to me to be an argument for imposing a particular structure on locspecs at the OHP level.
_(fwd link)__(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 locpsec?
 Davis et al. OHP: A Draft Proposal for a Standard Open Hypermedia Protocol (Levels 0 and 1: Revision 1.2 - 13th March. 1996). http://diana.ecs.soton.ac.uk/~hcd/protweb.htm
 Reich, S. How OHP's LocSpecs could benefit from ISO/IEC 10744. http://www.daimi.aau.dk/~kock/OHS-HT97/Papers/reich.ps
-Peter J. Nuernberg
HRL, Texas A&M University
This archive was generated by hypermail 2.1.5 : Tue 13 Aug 2002 - 07:20:33 CDT