From: Kaj Gronbak (kgronbak_at_intermedia.au.dk)
Date: Fri 16 Apr 1999 - 08:14:58 CDT
OHSWG, We are working on implementing our Structure servers such that they are fully compliant with the new darmstadt.dtd message format. In this process we discovered some inconveniences in the way contexts are handled.
Our notion of context:
A context is an object that holds a collection of hypermedia objects that are grouped together for some specific purpose. We wish to use context to implement the notion of a Web in Intermedia terminology, a Hypertext in Dexter terminology or a Hyperspace in Gronbak & Trigg terminology. I guess the corresponding term in Microcosm must be a link filter.
A typical scenario for a user is that s/he has several contexts open, e.g. s/he may have links and notes from two different contexts imposed on the same WWW document. The user may create a link in one context and create a node in another context from making the relevant selections in the UI.
Our problem with the current dtd is that the ContextIdSet is part of the messageheader rather than a parameter in the message.
As you may remember the Århus implementation is made as a set of interfaces where we have operations such as LINKCREATE, ENDPOINTCREATE taking relevant parameters. When we communicate over the wire these operations are translated into message according to the DTD. The convention here is: - the messageheader information is added by the infrastructure without intervention by the programmer using the interface. - the messagebody contains the paramters that the programmer supplied to the operation.
_(fwd link)_If we take the above scenario, it is inconvenient for the programmer to have to modify some "environment" variable to hold the id of the context in question before s/he issues the LINKCREATE operation targeted at one context and then modifiy that variable again before issuing the NODECREATE operation targeted at a another context.
We could of course modify the LINKCREATE operation such that it takes a contextIDSet as a parameter and then use that to explicitly modify the messageheader. But we see this as a not very clean solution since we then have some operation parameters that go into the messageheader and some that go into the messagebody.
Moreover, not all messages need to take place within one or more Contexts.
We beleive that at least the following messages should have a ContextIDSet
parameter: LINKCREATE, ENDPOINTCREATE, ANCHORCREATE, NODECREATE,
COMPUTATONCREATE, LINKFOLLOWFROMLOCSPEC. The corresponding delete operations may not need the contextIDset since we could implement the structure server such that it guarantees that if a Link, Endpoint, Anchor, Node, PSpec or Computation is deleted then it automatically removes the objectID from all the Contexts in which it is a member. This would emancipate the user from remembering all the relevant contexts to enumrate for a delete operation.
We can of course make either the environment variable workaround or the splitting of parameters into header and body parameters, but we would prefer the more clean solution with the ContextIDset as part of the messagebody in a revision of the darmstad.dtd.
/Kaj & Lennert
This archive was generated by hypermail 2.1.5 : Tue 13 Aug 2002 - 07:21:13 CDT