In general, there's a lot of agreement here with the
structures I've been developing (although I have not
been focusing on interfaces, as I should).
Some specific questions follow...
Lee Iverson wrote:
>
> So, what we've done above is to separate the structure of our tree
> into a set of *placeless* Nodes (some of which have children) and a
> Document tree defined in terms of Paths which define where Nodes are
> *placed* in a Document.
>
Question:
If nodes are "placeless", and a document is a collection of nodes,
how is that some nodes have children? Doesn't that give them a
"place"?
I'm trying to follow the structures here...
Ok. I see now. The Document is a tree of Path objects. Each Path
object contains a pointer to a Node, which in this version of the
interface could be either a TextNode or an ElementNode.
Questions:
Why does an ElementNode have a child?
Why is it a Node object, rather than a Path object?
A node that existed here would not have any existence
in the Path structure, would it? Doesn't that make
impossible to reuse substructure?
<SNIP>
> 3) Versioning: Again, it is the nodes which are the units for
> maintaining version information. Thus:
>
> interface Node {
> ...
> readonly attribute Node olderVersion;
> readonly attribute Node newerVersion;
>
> Node versionDated (in Timestamp time);
> };
>
Quibble:
Does "readonly" mean "writeonce"?
If not, "newerversion" is gonna have a hard time
being filled...
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 17:57:58 PDT