Modelling

There are many ways to do it

and just one to understand.

Preface

Internaly the information space described in the user view section is maped into so groves, a model developed for SGML documents. But it would be foolish to conclude that everything here "is somehow SGML", is just looks alike. The grove model, being used to describe all sorts of object like airplan parts (TODO dig out that reference again, around 1990) can do much more.

At the other hand some understanding of groves (TODO stick in references here) SGML and DSSSL helps not only for understanding the XSLT code.

Data Models

A proofen method to implement editors, which work on and modify data models is called Model View Control. It saw the light of the world with smalltalk (an object oriented programming language) and is found in many successful programing environments (e.g., Java).

TODO find a pointer to a good introduction and stick it in here. The reader should know enough to understand what the pieces are, no detailed knoledge required to read ahead.

This model has been explicitly retained. Actually it comes in at least two flavors:

Low Level Structure

There is nothing "approximate" here. Every mapping here maps exactly one-to-one

Please note: The aplication programmer is normally never concerned with concepts like locks and transactions, Every modification of the model data is a) ACID and b) happens only if there is no exception in the write method.

If you really need more complicated data models, you need to implement the required mechaniques at application level. That is, if you ask me, I'd feel you better clean up you data model.

MVC with XSLT

With XSLT style sheets, the code becomes partialy part of the data. I feel sorry to say that this blures the physical distinction between model data, view and controler code while the low level still maintains it.

The incomming message, to which the style sheet is applied, has an attribute named type, which indicates the low level mode. All templates, which apply when this attribute has the value "read" are part of the view code, while those, which are applicable for a "write" value belong to the controller.

The first node of the children of the reply document as constructed by the controller code (which is not an recognised extention) is the next state of the place (see the stream abstration, SICP). It contains again all three elements, those templates, which apply in read and write mode and other elements, typically xsl:variable, which can hold model data values.

Pipelining

A great strength of Unix and ~alike's like Linux is the principle to build complicated processes by pipelinging simple steps: the output of a step is fed as input to one or more others.

BTW: One could question the following for a certain user/situation, but over all those "steps" (tools like grep), which only produce some output and don't modify anything else appear to be most useful, because they are more manageble. (To put it different, they work purely function from a black box point of view and that matters.)

The same model pattern is found, when algorithm are solved using systolic arrays. TODO stick in reference.

You map such situations, by writing a read function, which performs the single, simple step on the incomming message and send the result to the next step.

Neuronal Networks

A design decision has been to retain strong topological and "kinematic" similarities to neuronal networks. But at a different level. Real neuronal networks exchange less structured data at higher rates, while this here exchanges human readable documents instead. Once we have faster or parallel computers and a good editor for them it might be interesting to map the neurons of networks into those places here.

Networks of parallel Processes

Highly parallel processes, e.g., workflows, are conviniently modelled using petri nets (maybe you sketch it with UML first, but that maps too trivial to serve as an example). See below how this compares to other modells.

Once your're done with the petri net, you need to map it into the information space as follows:

1. All petri net markings map into XML elements (except maybe, if you did not want and the process carried none-XML work load).
2. Petri net places (which doesn't directly map to the minds idea of a place) - here P1 to P4 - together with the code of all transitions, which follow them directly, go into one mind-place as shown in the picture below. At your choice, you might include more, but that's not wise.
3. Arcs from transitions to P's inside of other places map to named links of the place.

Programming with XSLT

With XSLT style sheets, whenever a message arrives at a place, the style sheet is applied to the incoming message.

Mapping the place in the middle of the picture could be done using a xsl:variable for each P2 and P3. The code for the transitions T3 and T4 might consist of a xsl:if, which give the condition under which the transition will fire. When the transition fires, messages are produced by the XSL-template contained in that xsl:if. The template of T3 will produce a message send to P4 and the template of T4 will produce the new state of P3. (Actually it's a bit more complicated: it'll have to reproduce the whole style sheet with then content of the xsl:variable for P3 replaced by the new value. This is not as complicated as it sounds.)