Re: [ba-ohs-talk] GUI Ideas and NODAL
----- Original Message -----
From: "Lee Iverson" <leei@telus.net>
To: <ba-ohs-talk@bootstrap.org>
Sent: Monday, November 12, 2001 7:20 PM
Subject: Re: [ba-ohs-talk] GUI Ideas and NODAL (01)
> 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.
>
> 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)
[ppj] Or you might gain a powerful generalisation, depending on what you
actually end up doing with the data.
I see your point, but I'm just wondering whether it's possible to step
beyond it by fixing aspects of the general (super)graph instead. Perhaps it
becomes too complicated. (03)
>
> 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.
>
> > 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.
>
> 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. (04)
[ppj] OK. Neat. I like the approach you're going for. But if that's the
case, why have you kept 'characters' as a primitive, and not just made the
string type the primitive, leaving char[]'s up to the implementation
concerned? (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?).
>
> 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.
>
> --
> --------------------------------------------------------------------------
-----
> Lee Iverson
> leei@telus.net #105-2700 Acadia Rd., Vancouver B.C. V6T
> 1R9
> http://www.ai.sri.com/~leei/ (604) 222-9312
>
> (06)