On Thursday 23 December 2004 12:53 pm, Michael Latta wrote:
> So I  
> would like to be able to attach a context to any set of shapes on a  
> diagram.  This may typically be all children of a node, but it could  
> also be a set of peer nodes.
>

Yes, I have also come to the conclusion that there needs to be much more 
awareness of contexts in general in our programs.

I would go so far as to say that what looks to us in Smalltalk like inherent 
behaviors and state (named slots of one sort or another) is actually only one 
of many possible views of our software world. However, the language itself 
doesn't directly support the concept of contexts.

Dan's Environments, namespaces, the Visitor pattern, Aspect Oriented 
Programming and many other software artifacts are, in my opinion, attempts to 
get around the context problem.

Looking at objects as relatively static collections of named slots is limiting 
in many ways. For one thing, it does not easily handle the problem of schema 
migration and versioning.

Avi Bryant and I were talking about (and he and Andrew Catton are working on, 
I believe) an alternative object model in which the context is everything. 
That is, each context contains a set of tables of tuples that map atoms 
(bidirectionally) to other atoms. Atoms are immutable things like strings, 
numbers, object IDs, pictures, etc.. Besides the two atom references that 
define the relations, the tuples may also contain timestamps or other 
metadata. The tables themselves may have human-centric names within a context 
(they also have immutable IDs).

One advantage of this model is that it is quite easy to use over a network 
while still maintaining security. By sending appropriate slices of selected 
tables and whatever atoms do not already exist on the other end of the wire, 
we can limit or modify views of our data space.

It also lets us maintain different structures and relationships in different 
contexts. This is important for collaborative work, especially if the 
connection is intermittent (which is important to me with respect to 
distributed work and end-user computing).

For instance, I may be working on some model of some part of my world in which 
(in one context) I like to think that there is a "organization" attribute to 
some of my objects. This is represented by a relation table that I call 
"organization" in that context. When I share some view of my model with 
someone else (perhaps by emailing them a view), I may not decide to include 
any part of this table. So they may decide to add an "organization" attribute 
themselves. If they work on this model and send me a new copy that has their 
"organization" table, it's no problem because the names aren't important to 
anybody but the person using them (in code that I wrote in that context, 
references to "organization" are actually bound to that specific table, not 
its name). For convenience, I may decide to rename that table to something 
else that is more meaningful to me, or hide it in that context, but 
everything still keeps working. Similarly, the tables may have multiple names 
-- one for each of several languages, for instance.

So what is an object in this system? An object is nothing more than its 
identity (an atomic ID). To actually use it, of course, it has to be related 
to other atoms in some way. So we can go further and say that it is its 
identity, along with all its active relationships within the context(s) of 
interest.

It's not possible to navigate from an object to its attributes. You have to do 
this through the relationship tables.

Anyway, this has direct parallels to the problem of multi-level graphs and 
their relationships (there has been a lot of work done in the field of graph 
transformation that deals with mappings between graphs, and with graphs that 
represent structure and constraints of other graphs).

We could view each of these relation tables in the model I described above as 
an (unlabeled) representation of an edge. However, in the model I described, 
individual tuples in a relation table are not themselves atoms and are not 
directly addressable. This makes it hard to label an edge if it's represented 
in this way, as there's no way to refer to that relationship directly.

However, it's also possible to represent edges in a more standard way, using 
two relation tables (one for each vertex attached to an edge). Now we can 
have edges be actual objects; each one is represented minimally as:

vertex1ID <=end1=> edgeID <=end2=> vertex2ID

where vertex1ID, edgeID, and vertex2ID are atoms (objects) that consist of 
nothing more than a UUID. And end1 and end2 are tuples in two different 
tables.

Labeling this edge with other data is now simple, since it's a real object:

edgeID <=edgeName=> 'fred'
edgeID <=edgeColor=> 'red'

and of course edgeName and edgeColor are tuples in tables that are contained 
in (or at least associated with) some context(s).

> Allowing end-users define the mapping and styling of the diagram  
> presentation is very powerful, and requires a very well thought-out  
> interface.  I would like to dialog on this, as my new project will need  
> it, and I have some experience that may help in designing it.

This is interesting to me, also. I have thought that prototypes and examples 
may give us something useful to work with. That is, allow an arbitrary 
drawing to be associated in some way with (possibly new) model data. So 
there's no extra work necessary in the simplest case; the user merely styles 
some view of some subset of their live data the way they want.

The system can then help refine the rules that determine how this new example 
drawing relates to what it needs to present. For instance, if the user draws 
the same kind of relation two different ways in one or more example drawings, 
the system can note this and further determine when to use one or the other 
by asking a few questions and/or providing some sensible choices.

In the absence of ambiguity, the example drawings are used to specify the 
style for new relationships of the same kinds within drawings of the same 
kind.

Since you have a metamodel (which may itself be editable) that specifies the 
type graph of your system, you can impart meaning to the example drawings by 
mapping them to the type graph.

-- 
Ned Konz
http://bike-nomad.com/squeak/