Re: [ba-ohs-talk] Node Object model; WAS: GUI Ideas and NODAL
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...
> } (01)
This is all fine. In fact exactly the idea (with some twists) behind
the basics of the Nodal data model. (02)
> 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?
> } (03)
This is straight out of the Nodal stuff. (04)
> 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?) ? (05)
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). (06)
[The next bit may start into obscurity... Stop me if I'm going too
fast...] (07)
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? (08)
--
-------------------------------------------------------------------------------
Lee Iverson
leei@telus.net #105-2700 Acadia Rd., Vancouver B.C. V6T
1R9
http://www.ai.sri.com/~leei/ (604) 222-9312 (09)