Re: [ba-ohs-talk] Node Object model; WAS: GUI Ideas and NODAL
Lee Iverson wrote:
> So, in the Nodal data model a Node has the ability to enumerate its
> "children" but an Atomic type does not. There are a couple of twists
> on this however. The Cursor is used as a proxy object for Nodes that
> encapsulates an access context, including User and Path references.
> In fact, my thinking has evolved to a point where I think that the user
> interfaces should completely hide the "Node" interface behind Cursors.
> Navigating through the graph will involve enumerations of "children"
> that return Cursors with the same User and augmented Paths. Thus, even
> though no Node has a parent (and is thus indiscriminately reusable),
> actual navigation through the document graph is done via these Node
> proxy objects that hold a Node reference augmented by the navigational
> context. The Cursor is this context object and it combines navigation
> and content access and editing interfaces in a package within which
> access control decisions can be made. Whew! More? (01)
I had to read it about 10 times, but I think I'm getting there.
Skipping Paths a moment...
So basically what happens is that the Node class I sketched above has some
permissions set on it - various, reflecting the total user group directory
preferences for that node.
Then the Cursor object walks the Node graph and only 'picks up' a node to
create a new Cursor if the permissions match. (02)
Bringing Paths back in...
Users with the same permission set may nonetheless create subsequent node
graphs from the available node set that are not isomorphic. This was where I
would bring in my Node-Views from the GUI ideas. So the issue of unique user
plus group permissions plays with Paths in a big way. Semi-rhetorical
question: If the idea was collaboration over a document then how is that
dealt with?
The group can see who did what over time. And if I wanted to create a unique
view for some reason then I could create a copy of the collaboration
document with the permissions raised to 'mine only'. (03)
Am I still on the right track? (04)
Cheers,
Peter (05)
----- Original Message -----
From: "Lee Iverson" <leei@telus.net>
To: <ba-ohs-talk@bootstrap.org>
Sent: Wednesday, November 14, 2001 7:36 PM
Subject: Re: [ba-ohs-talk] Node Object model; WAS: GUI Ideas and NODAL (06)
> On Wed, 2001-11-14 at 06:06, Peter Jones wrote:
> > To continue this strand...
> > Taking this model
> > Node <= {[Node <link> Node] && [Node <link> Node], ...}
> > Acually, each value node (2nd node in each pair) can be very effectively
> > represented as a child of the key node. So the top level node can just
be a
> > vector of key nodes, and the child of a key node is a value node. (Hence
my
> > plastering the term vector over previous mails. ;-)
> > That basic structure can handle map, struct, and sequence all with the
same
> > interface.
> > Which means I can have a basic node that looks something like,
> >
> > (N.B. the following is pseudo-code of sorts.)
> >
> > class Node
> > {
> > private:
> > Enumeration e;
> > //ignoring any other frills for now
> >
> > public:
> > //yadayada...
> > }
>
> This is all fine. In fact exactly the idea (with some twists) behind
> the basics of the Nodal data model.
>
> > Then to handle the node type I just implement a modification of the Type
> > interface Jack just passed me
> > //in Java
> > public interface Type extends Nameable {
> > boolean accepts(boolean b);
> > boolean accepts(byte b);
> > boolean accepts(char c);
> > boolean accepts(double d);
> > boolean accepts(int i);
> > boolean accepts(Node v); //changed from Object to Node
> > boolean accepts(Date d); //added
> > //..and so on for all atomic types
> > // boolean accepts(String s); //needed if string is sequence of char?
> > Object as(boolean b);
> > Object as(byte b);
> > Object as(char c);
> > Object as(double d);
> > Object as(int i);
> > // Object as(Object v); //break this down into atomic types
> > // Object as(String s); //still needed?
> > }
>
> This is straight out of the Nodal stuff.
>
> > Then the atomic types are just restrictions (subclasses) of Node to
hold a
> > specific type and to limit the number of entries in the vector.
> > e.g.
> >
> > class CharNode extends Node
> > {
> >
> > private boolean full;
> >
> > public setNode(Object ch)
> > {
> > //setting stuff
> > full = true;
> > }
> >
> > //...etc
> > }
> >
> > Does that make any sense? Or am I way behind folks (Lee?) ?
>
> Two problems. In the Nodal data model, Nodes and Atomic types are
> distinct. The key here is that a Node is a metadata holder,
> navigational unit, *and* content holder. An atomic type is simply
> a content element (and we want to encourage atomic types to be handled
> efficiently as value types).
>
> [The next bit may start into obscurity... Stop me if I'm going too
> fast...]
>
> So, in the Nodal data model a Node has the ability to enumerate its
> "children" but an Atomic type does not. There are a couple of twists
> on this however. The Cursor is used as a proxy object for Nodes that
> encapsulates an access context, including User and Path references.
> In fact, my thinking has evolved to a point where I think that the user
> interfaces should completely hide the "Node" interface behind Cursors.
> Navigating through the graph will involve enumerations of "children"
> that return Cursors with the same User and augmented Paths. Thus, even
> though no Node has a parent (and is thus indiscriminately reusable),
> actual navigation through the document graph is done via these Node
> proxy objects that hold a Node reference augmented by the navigational
> context. The Cursor is this context object and it combines navigation
> and content access and editing interfaces in a package within which
> access control decisions can be made. Whew! More?
>
> --
> --------------------------------------------------------------------------
-----
> Lee Iverson
> leei@telus.net #105-2700 Acadia Rd., Vancouver B.C. V6T
> 1R9
> http://www.ai.sri.com/~leei/ (604) 222-9312
>
> (07)