Justification of the approach

As mentioned elsewhere, the conversion from Vensim's MDL language to Simile's Prolog language involves 3 separate steps:

  1. conversion from Vensim's MDL to a corresponding XML (Vensim XML);
  2. conversion of Vensim XML to a corresponding Prolog (Vensim Prolog);
  3. conversion of Vensim Prolog to Simile Prolog.

This page sets out that thinkingthat led to this approach.

The conversion between other model-representation lanugaes and Simile operates at two levels:  

First, there are fairly minor syntactic dfferences.  For example, in Vensim a variable name (as used in an equation) may contain spaces; whereas in Simile the variable name in the equation cannot contain spaces, and these are replaced by underscores when the label provided by the user does contain spaces.   This type of conversion can usually be done on a line-by-line basis.

Second, there are much more substantial structural differences in how the models are represented.   In Vensim, the mathematical part of the model is eqpresented by a set of equation statements, followed by one or more "views", which give information defining how the model or part of it is actually displayed.   In Simile, the mathematical and diagrammatic information is represented by two statements which immediately follow each other, with a separate link statement to join them together.   This type of conversion is much more complex.

So, let's start with the hardest part first.  What is an appropriate computing approach to use to convert from one symbolic representation to another, when both contain the same information but arranged in quite different ways?   I decided to use the logic-programming language Prolog ("Programming in Logic") for this task.   I hesitate to say "it's the best", because that implies that I have thoroughly researched the field and chosen it from various competing approaches, which I haven't.  However, I can say that it is very well suited to this task, for a number of reasons:

  1. It is a language specifically designed for reasoning with symbolically-represented information, which is what a model representation is, whether it's a Vensim or Simile model.
  2. It is a declarative language. You don't tell the computer what operations to perform, as you do with a conventional programming language.  Rather, you make statements about relationships, in the form of rules, and it's up to the prolog interpreter to solve a problem by using these rules.  In the present context, 'solving a problem' means finding a Simile representation which corresponds to teh Vensim representation.
  3. One benefit of the previous feature is that a Prolog program is blissfully free of many of the procedural structures you need in a conventional programming language - for example, loops to iterate over many possibilities.   This makes the Prolog program much more light-weight, and therefore easier ti write and maintain.
  4. Any part of the Prolog program can be tested by itself.   The full program for transforming from one language to another will consist of many rules.  However, any one rule can be tested to see if it's working - you do not need to write special code to exercise some small part of the program, as you would normally need to do.
  5. Finally, because Prolog is a declarative language, it has the potential for writing the transformation rules so that they can be used in either direction - from Vensim to Simile or from Simile to Vensim.   This has not been done in the present Prolog context (though it has for the XSugar parts - see below), but the potential is there.   This would mean that the rule set has to be written only once, ratherthan writing two totally separate converters.

One implication of deciding to use Prolog for the main structural conversion is that the Vensim model must be represented in Prolog syntax.   It doesn't matter what Prolog syntax, just anything that the Prolog interpreter can interpret as valid Prolog facts.   However, Vensim's MDL format is not in Prolog syntax.  It is therefore necessary to convert from the MDL into Prolog.   Unlike the structural conversion considered above, this can be on a direct, one-to-one basis, merely marking up one syntax (MDL) with the conventions of another (Prolog).   What is the best way of doing this?

This is where XSugar comes in.  XSugar was specifically designed to allow for the conversion between one syntax and another.  Moreover, it has been designed so that (subject to certain conditions) the conversion is reversible: the same rule-set can be used to convert in either direction.   So it seems ideally suited to our needs. 

The problem is that XSugar is specifically designed to convert between a non-XML ("plain text") syntax and XML  For example, a simple XSugar rule could specify the mapping between

Charles Darwin; The Origin of Species

and

<book><author>Charles Darwin></author><title<The Origin of Species</title></book>

So, if we want to go from Vensim's MDL to a Vensim model in Prolog, we would need two XSugar conversions:

  • from Vensim MDL to an XML syntax for Vensim models ("Vensim XML); and
  • from Vensim XML to a Prolog syntax for Vensim models ("Vensim Prolog") (using an XSugar stylesheet in the reverse direction, i.e. from XML to Prolog text).

This sounds arduous.   In fact, once you have the first stylesheet, it is pretty easy to make the second, because it will have the same number of conversion rules, and the XML part is the same in both cases.   So it's actually a small part of the whole exercise.

The complete conversion process thus consists of three steps:

Vensim MDL --> Vensim XML --> Vensim Prolog --> Simile Prolog.

of which the first two have guaranteed reversibility.  If one subsequently wants to convert in the reverse direction, one need only write the Simile Prolog --> Vensim Prolog converter; or re-write the Vensim Prolog --> Simile Prolog converter so that it too is reversible.