On Dec 23, 2004, at 2:21 PM, Ned Konz wrote:

> 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).

I built one system based on atoms and tuples.  It has some advantages 
over objects and pointers, but also has some problems.  The biggest 
problem is separating out the facts the user cares about, and those 
that are there to make the system work.  I think it can be made to 
work, but as always needs some thought and hard work.  The big 
advantage was a uniform data model that allowed easy transaction 
management and undo/redo.  I have not come to a final conclusion on 
whether I would again use that model.

>
>> 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.

Our current model uses type based mappings as you describe.  The user 
can attach mappings at abstract or leaf level types.  While this works, 
there are many other conditions that also need to be distinguished.  We 
do that currently in the mapping from the core model to the diagram 
model, so the styling can always be done by type.  Your idea of having 
the system check for different examples being of the same type but 
different style has merit.

What is your time line for working on the graph model part?  If I get 
this new project off the ground, I will be looking to deal with this 
very quickly.  I may end up having to roll my own, if your plans are 
too general or you have other priorities.  Let me know.

Michael

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