hmmm...
How does is a Property which is a NodeList represented?
What about a integer/string/boolean Property?
Or even worse, and integer list or a string list!
Unfortunately, at one point I spent over a week trying to come up with a
simple but powerful grove interface. It just ain't that easy.
I think it would go more like...
public class Value {
public String m_string;
public int m_integer;
public bool m_bool;
public Vector m_list;
public int m_type; // what kind of data does this value contain
}
public class Property {
public String m_name;
public Value m_value;
}
public class Node {
.... as listed ...
}
The other minor problem is that the child(ren) are defined by the value of
a property (which property is specified on the classdef).
I am not convinced that it is really worth implimenting groves this way
though. Groves are designed such that it is often easier to duplicate
information, in a slightly different form, than to just reference it.
Sometimes you have to. For example each element has it's GI as a string
valued property. It also has the same information encoded as a reference
to the element type. When I was working on a general Grove interface I
came to decide that it really should be a grove specific set of classes
which build on some more primitive interfaces (such as node,
property_value), and which impliment properties as methods. This also
opened the door to such functionality as concurent construction (a property
value may be 'not-available-yet') which is necessary for an online
environment.
A the time I also had a SP Application which parsed property sets into some
C++ data structures, which I then used to generate teh stubs for the grove
interface. The project never was really finished, and I have since moved
jobs... so I can't really go back an look at it, though I may be able to
get a copy of the SP app.
-derek
-- Remember: Computers are here to make our lives easier --
ddb@criinc.com // software-engineer // www/sgml/java/perl/etc.