In message <3A53D94B.DBA0AD89@eng.sun.com>, Eric Armstrong writes:
>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"?
A Node *itself* is placeless, in that it doesn't know where it is
located in a hierarchy. The GroupingNode objects can have children,
but the children themselves don't know that they are children of that
particular node.
The easy way to think of this is that in order to know *where* it is
in a tree, a Node must be able to at least trace the sequence of its
parents up to the root. In the model I've described that operation
cannot be done by a Node, but instead requires a Path object, which is
defined wrt. a particular Document. So, a Node has no identifiable
parent, and thus no "place". This is not in any way in conflict with
the fact that some Nodes have children.
Since editing structure requires a definite context, that is all done
with respect to Paths.
>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?
This is partly explained above. A key observation for reusing
structure is that any particular Node may be inserted into position
using any EditablePath object, irrespective of which Document the Path
is in or how many other Paths exist which contain that Node.
> <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...
In IDL, a "readonly" attribute cannot be modified using this
interface. The olderVersion and newerVersion attributes are
maintained by the editing methods in the EditableElementNode.
I do need to verify that "readonly" allows for the possibility of
being remotely modified and is thus *not* a guarantee of
non-volatility. If that is the case then we can just change to:
interface Node {
...
Node olderVersion ();
Node newerVersion ();
Node versionDated (in Timestamp time);
};
That may actually be preferable anyway.
-------------------------------------------------------------------------------
Lee Iverson SRI International
leei@ai.sri.com 333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/ (650) 859-3307
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 17:57:58 PDT