[Date Prev] [Date Next] [Thread Prev] [Thread Next] Indexes: Main | Date | Thread | Author

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
> > necessary to have these three distinct types if nodes are built up of
> > 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
> > 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
> > should be transparently a node or node-composite, in as simplistic terms
> > 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
> > prove very controversial. For me, a text document should just be a
> > of characters (char[]) at the lowest API level, with '\n' just being
> > character. The interpretation of '\n' as a line-breaking character
> > on the task in hand. This means that I might want to optionally specify
> > the file data is picked up depending on what I have in mind. Most
> > programming language already have a 'getline' type function in their
> > 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
> > previously only a single char[] has to become a sequence of nodes, some
> > 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
> > (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)