Re: Requirements document for the September OHS meeting

From: Jim Whitehead (ejw_at_ics.uci.edu)
Date: Mon 09 Jun 1997 - 16:10:40 CDT


>As a first step towards a requirements document for future versions of the
>OHP, I've gathered issues from the position statements from our OHS
>workshop at Southampton. We still have a ways to go to generate actual
>requirements from these topics. In fact, final requirements may not emerge
>until we're together at the September OHS workshop in Aarhus, Denmark.

Thank you for taking the time to collate this list of issues from the workshop position papers!

>The groupings I came up with were those that made sense from the position
>statements. The groupings are in no particular order, and of course,
>there's overlap between some of them. We may well want a different
>organization for the actual requirements document (e.g. something
>corresponding more closely to the structure of the OHP).

However, while collecting this list of issues is very important, and will serve as an important reality check for the final requirements document, I fear that starting off with such an encompassing list could lead to the development of an overly broad requirements document. If this group were to develop an interoperability protocol for collaboration, versioning, guided tours, and consistency maintenance, then my experience tells me that this group is looking at 2 more years of work, minimum. I recommend we keep our scope *very* limited.

_(fwd link)__(fwd link)__(fwd link)_How broad should the OHP be?

_(fwd link)_I think the OHP would be a raging success if it only accomplished the following:

_(fwd link)_Browse functionality:

- develop an interoperable locSpec
- allow an OHP client to retrieve a document from an OHP server
- allow an OHP client to initiate a link traversal

This would allow the reuse of OHP clients from many Open Hypermedia Systems for browsing activities. Editing activities would still need to be performed by using system-specific clients.

Why limit things to just browsing? When you start allowing editing capability, you start down a slipperly slope. If you allow authoring capability, then you also need locking, access control, and authentication, which are large issues (like, what's an interoperable way to edit computational links, or how do you define a lock which has the same semantics across all OHSs?) Editing capability often goes hand-in-hand with namespace management capability, like copy, move, and list directory, which are also surprisingly tough issues.

If we limit ourselves to just browsing functionality, I suspect we'll find several meaty issues (locSpecs and Channels are two), yet we'll still be able to finish the spec. in a reasonable time frame. Once finished, we can then move onto the editing problems.



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