Primitives in OHP expressed in IDL (and explained)

D. E. Millard, S. Reich, H. C. Davis
Multimedia Research Group
The University of Southampton
SO17 1BJ, Southampton UK
{dem97r, sr, hcd}

Oct 13 1998

This report is about primitives (or performatives) that we propose to use as an underlying layer for the different Hypertext domains to be addressed by the OHSWG's interoperability effort. In particular we have had many discussions (here in Southampton) how to actually specify the primitives using IDL (the usage of IDL has been agreed at the last working group meeting in Southampton).

As the IDL we are using is an abstract definition we can use the IDL for defining both, the primitives' layer and the domain layer even though this may result in two seemingly independent specifications. The following Figure expresses these different layers.

We see the main benefit of primitives in being able to communicate about messages. This would mean that two components of different domains such as a navigational component and a spatial component would be able to negotiate at least at a basic level. This is what we attempt to express in the following IDL definition:

#include "ohpdatatypes.idl" 

interface OHPPrimitives {
  union ParamVal switch (long) {
  	case 1: string str;
	case 2: AbstractObject obj;
  struct Parameter {
        string name;
        ParamVal value;
  typedef sequence<Parameter> Parameters;
  void ask(in string opCode, in AbstractObject o, in Parameters params);
  void notify(in string opCode, in AbstractObject o, in Parameters params);
  void error(in string reason, in string theOperationWhichWentWrong);

  void askstream(in string opCode, in AbstractObject o, in Parameters params);
  void eos();
  void cancel();
  void advertise(in string opCode);
  void unadvertise(in string opCode);

  void subscribe(in string opCode);
  void unsubscribe(in string opCode);

This specifies each primitive as a function. Functions take an operation code, the object on which the operation is to be performed as well as a list of parameters. We have not included other perhaps necessary information such as message header, etc. An implementation of this obviously would have to do that!

We do not specify exceptions because we cannot assume all possible implementations to support exceptions (the same as we cannot assume these systems to be object-oriented).

The following table explains which sequences of primitives are allowed (IDL does not allow us to specifiy this).





ask notify | error -
notify NIL| error ask
error NIL -
ask-stream (notify*, eos) | error -
eos NIL | error ask-stream
cancel NIL | error ask-stream
subscribe NIL | error advertise
unsubscribe NIL | error subscribe
advertise NIL | error -
unadvertise NIL | error advertise

Note: | means XOR; NIL means nothing expected; * means 0 or more

For the different hypertext domains additional specific IDLs are to be developed. For the navigational domain we believe that this looks very much like the current Danish proposal. Things that might need changing include the definition of subscriptions, etc. We will be looking at this very soon.