Re: [ba-ohs-talk] GUI Ideas and NODAL
On Mon, 2001-11-12 at 05:56, Peter Jones wrote:
> Hi Eugene,
>
> >MapNode, SequenceNode, StructNode -- are equivalent to
> > hashes, lists, and structs.
>
> Yes, thanks, I'd understood that. What I was really asking is "Is it really
> necessary to have these three distinct types if nodes are built up of other
> nodes?" (I'll have to practice writing better questions.)
> For instance, does the distinction between Sequence- and StructNode, and
> MapNode types go
> away if the Enumeration interface-implementing data class you use can store
> different types at the same time (e.g. Vector) ?
> And I might implement a property-value pair as a link node between two
> nodes, and a MapNode as a Vector of LinkNodes.
>
> What role(s) do the derivative types, Map, Seq..,Struct really play?
>
> In the GUI ideas I posted I wanted everything to be a Node (hyperlink
> LinkNodes were a specialisation of Node), and a node was defined by its
> content and any (type-)name(s) it might have. My view was that everything
> should be transparently a node or node-composite, in as simplistic terms as
> possible, as far as the user view is concerned. (01)
Well, there are really a number of reasons to separate these out. The
most obvious one in my mind is simply that manipulating these three
kinds of collections (from an object-oriented point of view) is very
different. The operations performed on a Struct, Sequence and Map are
just completely separate. A Struct has a fixed set of fields and one
may only assign new values to them. A Sequence has a set of items of
uniform type and we can insert or delete subsequences or set individual
items. A Map indexes its values via keys of a defined type and we can
either assign values to keys or remove keys. It is certainly true that
we could emulate these behaviours with simpler constructs, but then we
would lose a great deal of the expressive power of our data modelling
language. (02)
Remember that one of the fundamental goals of the NODAL
data model was the ability to transparently map existing file types
and programming language constructs onto the model. With anything less
than these types, I'd have a hard time making that claim. Looking at
modern ODBMS systems (and especially the ODMG's proposed standards),
these building blocks seem to map directly onto current object database
constructs as well. (03)
> And I'm not sure I agree with the definition of a text document as solely "a
> sequence of lines, represented as strings". I think this point is going to
> prove very controversial. For me, a text document should just be a sequence
> of characters (char[]) at the lowest API level, with '\n' just being another
> character. The interpretation of '\n' as a line-breaking character depends
> on the task in hand. This means that I might want to optionally specify how
> the file data is picked up depending on what I have in mind. Most
> programming language already have a 'getline' type function in their core
> libraries. (04)
Well, you are ignoring the fact that various systems define line endings
very differently (e.g. line ending semantics on MS vs. Unix vs. Mac
systems). The text encoding for exactly the same file is different on
these systems but the data model is identical. (Properly then, the
"line" strings in such a file should exclude these line-ending
characters ("\r\n" in C parlance). That is not to say that you can't
define a file type that is simply an undistinguished sequence of
characters for your own purposes. It's not what I have in mind though. (05)
> Where that idea breaks for me, is that I will want to insert other nodes
> (childNodes) into the stream of text content, in which case a node that was
> previously only a single char[] has to become a sequence of nodes, some of
> which are char[] and others which are not because they hold data further
> down the branch of the tree. However, this is probably not that difficult
> (he says, with fingers and toes crossed) to program.
> Tracking node changes then becomes trickier though as the node histories
> somehow have to register the split (or merger?). (06)
Now you're talking about something that is no longer a plain text file
(it has content other than just characters). Again, if you need a file
type that has content other than just lines of characters, you'll have
to define a new document type. This is should be easy enough to do. (07)
--
-------------------------------------------------------------------------------
Lee Iverson
leei@telus.net #105-2700 Acadia Rd., Vancouver B.C. V6T
1R9
http://www.ai.sri.com/~leei/ (604) 222-9312 (08)