From: Peter Nuernberg (pnuern_at_daimi.aau.dk)
Date: Wed 10 Jun 1998 - 10:18:57 CDT
This is a rather lengthy mail describing some of the details of the first OHSWG standards implementations that will be demo'ed at HT 98. This message is divided into several sections. Section 1 gives some background. Section 2 describes some of the progress we've made on the standardization front. Section 3 describes the sample implementations that will be demo'ed at HT 98. Section 4 describes what we can demonstrate. Section 5 discusses some open issues. Section 6 lists some resources.
Although we are still to date without a formally adopted referenece architecture, we seem to have come to an agreement that the "middleware" layer of hypertext systems/environments consists (conceptually) of several components. Each component implements some interface. Our standardization effort addresses in part the definitions of these interfaces. It also addresses how (physically) to deliver these services to clients, as well as issues that cross interface boundaries (such as naming).
The entire standardization effort has gone under the name "OHP".
Individual interface standards have gone under the names "OHP-x", where
"x" is some abbreviation. The only interface standard to have received
any substantial attention to date is OHP-Nav, which is the proposed standard for the interface to components that serves "traditional" navigational (link/node) structure. Initial efforts are underway on the OHP-Space (spatial hypertext) and OHP-Work (hypertext-based workflow) interfaces. There have been discussions about the possibilities of OHP-Lit (hypertext-based literature), OHP-Tax (taxonomic hypertext), and other interfaces.
Progress on many fronts has been frankly slow or non-existent. However, enough has come together to allow initial implementations of OHP-Nav compliant clients and servers. Some specifics of the relevant work is below:
OHP-Nav service definition-
initially agreed to at OHS 3.5 and confirmed by the
"on-the-wire" (OTW) subgroup, we are using IDL to define the interface
definition. The OHP-Nav interface definition _as implemented_ by numerous groups (see below) will be made available shortly. It differs in small details to the last publicly circulated draft.
OTW component framework choice-
OTW subgroup has decided on Java Beans / RMI as a suitable component framework for implementing OHSWG standard compliant servers and clients. At the time of this writing, no fully compliant OHP-Nav beans have been written.
OTW non-framework definitions-
OTW subgroup was also charged with defining a way to send messages over TCP connections between entities that could not or did not choose to use RMI to send requests and notifications to one another. The subgroup has not officially come to any decisions regarding this. However, since all the current implementations of OHP-Nav compliant software use TCP-based communication, there has been a de facto standardization of the non-framework communication format. We have chosen to define messages as (essentially) XML documents and message suites with XML DTD's. The XML DTD for TCP based OHP-Nav communication will be made available shortly. With minor work, the bytes streams generated by implementations of OHP-Nav servers and clients can be verified using one of many freely available XML validating parsers.
There are currently three sets of OHP-Nav compliant software that have been tested with one another. These are:
is a joint codebase successor to the HOSS and HyperDisco systems. There is currently a multi-user, multi-session OHP-Nav compliant server named NavMan and a wrapper process that wraps an integrated GNU Emacs.
DHM Hypervise client ("client side foo" in current OHSWG architecture terminology) has been integrated to speak OHP-Nav. Currently, tests have been carried out with an integrated MS Internet Explorer speaking to the CSF. Other clients may be tested with the OHP-Nav compliant CSF before the HT 98 demo.
Southampton demo software consists of a compliant server and a compliant CSF. Tests have been carried out with a custom-written JPEG viewer that speaks to the Southampton CSF. Other clients may be tested with the Southampton CSF before the HT 98 demo.
Ken Anderson is at work to convert some of the Chimera software to the current OHP-Nav standard. This may be completed by the time of the HT 98 demo.
Some groups hope to make available substantial portions of the above implementations at the demo.
4. What we can demonstrate
On the interoperability front, we have tested the following to date:
Construct client / Southampton server DHM client / Construct server Southampton client / Construct server
We expect that the missing combination (DHM client / Southampton server) will be tested before the demo. There are no plans for an OHP-Nav compliant DHM server for the demo.
In addition to exercising the "basic" functionality in the
specification, we have tested collaborative authoring sessions across
different machines and clients from different groups, as well as
"collaborative browsing", or the possibility for multiple clients to
receive the same traversal result (endpoint display notification), although currently, the latter requires the Construct NavMan, while the former requires both the NavMan and that collaboratively authored links (not their endpoints) be created by the Emacs wrapper. We expect that the Southampton and DHM CSF's will be modified to allow the creation of collaboratively authored links by the time of the demo.
5. Open issues
The demo implementation effort has pointed out a number of areas and issues not addressed well or at all by the current OHP effort. Some of these issues are listed below:
Currently, there is no clear picture of what a CSF is exactly or whether or not it s required. This must be resolved for our standards to avoid underdefinition.
has been no progress on object or entity naming. The two current compliant server implementations use disjoint namespaces. Although this works, we may want to examine benefits of unified namespaces.
location is currently done by convention, which themselves vary between the server implementations. This must be addressed by the group.
servers expect that clients maintain a connection across their lifetimes. Provisions should be made for clients that wish to use connections that persist only for the lifetime of requests or notifications.
is no defined state for compliant servers or clients, making collaborative link authoring difficult. (It is currently accomplished by keeping state in the Emacs wrapper, and hopefully, by the time of the demo, in the DHM and Southampton CSF's.) This issue must be addressed.
OHP-Nav issues -------------- OHP-Nav service set weight v. power- The OHP-Nav service set consists of nearly 40 services, many ofwhich go completely unused in all implementations (making it somewhat heavyweight). In comparison, many proprietary client protocols consist of a much smaller number of messages, thus pointing to the possibility of a lighter, smaller protocol, even if we keep the current data model. Also, many "common" operations require several OHP services, suggesting that the current service set consists of insufficiently powerful operations.
document clearly describes the intended semantics of the OHP-Nav services.
No session semantics are defined in OHP.
provisions are made for locking.
provisions are made for permissions granting or checking.
provisions are made for versioning.
The OHSWG WWW site (http://www.csdl.tamu.edu/ohs/) contains more
background material as well as archives of the traffic on this list
and lists for the various subgroups of the Working Group. There is an
"HT 98 demo site" (http://www.csdl.tamu.edu/ohs/ht98demo/) that
contains some discussions specific to the demo. Sigi Reich has assembled much information relevant to the demo and the OHSWG's work (http://www.ecs.soton.ac.uk/~sr/...). You should be able to find up-to-date XML and IDL specifications on Sigi's page. They will be moved to the official sites shortly.
The specifications referred to above will be posted on the OHSWG site shortly. A version of the Construct software will be made available at the HOSS and HyperDisco WWW sites (http://www.csdl.tamu.edu/hoss/ and http://www.aue.auc.dk/~kock/projects/HyperDisco/) by the time of the demo.
A Construct NavMan available for public use is kept running on
"sundew.daimi.aau.dk:9000". This will (hopefully :-) remain running
until the time of the HT 98 demo, except for periodic updates. The source for the Construct NavMan, a test client, the Emacs wrapper, and the Emacs elisp integration library are available upon request (mail to "pnuern_at_daimi.aau.dk" or "ukwiil_at_aue.auc.dk").
The Southampton Navigational Link Server is also available for public use at "lewey.ecs.soton.ac.uk:7777". Software is available upon request from "dem97r_at_ecs.soton.ac.uk"; these include the Soton CSF and associated tools, ImageViewer and the java component of the Link Server (N.B. it requires a jdbc compliant database, it has been prototyped with MS Access).
This archive was generated by hypermail 2.1.5 : Tue 13 Aug 2002 - 07:20:57 CDT