SMILE and XMILE

This forum is for discussion of the System Dynamics model representation standard XMILE. Discussion here will be monitored by the Society's technical standards committee with ideas and concerns conveyed to the OASIS Technical Committee responsible for defining the standard.
Forum rules
Please note: By posting here you grant permission to the Society Technical Committee members to repost with attribution on the OASIS discussion forum. If you have material for which you wish to maintain copyright control please post a link to the copyrighted work.
Magne Myrtveit
Posts: 57
Joined: Mon Jan 12, 2009 6:52 am

Re: SMILE and XMILE

Post by Magne Myrtveit » Sun Aug 18, 2013 7:34 am

Hi Bob,

Yes, storing redundant information inside the XMILE file might be a good idea. The main challenge, however, is to come up with a common definition of the main concepts. As you can see from the WIP example, the concept of arrays (subscripts in Vensim terminology), differs significantly. We need to re-visit every major concept and take great care to understand the different approaches, look for ways to transform between them, and select solutions that are not bound by history at the expense of good language design and the road forward.

Have a nice Sunday, Bob. I think I'll go for a bike ride :-)

Robert Eberlein
Site Admin
Posts: 179
Joined: Sat Dec 27, 2008 8:09 pm

Re: SMILE and XMILE

Post by Robert Eberlein » Mon Aug 26, 2013 5:41 am

Hi Everyone,

My conclusions from this discussion (those related to the original topic as the discussion did wander significantly from this).

1. We need to have a name for the computational specification language. It is currently SMILE and I would prefer to change that because I find it confusing.

2. When we present the language we should do so in a format that maps very easily to nested XML tags. I would suggest using labels and indentation to accomplish that as in:

Model: WordOfMouth
---Variable: FruitfulContacts
------Equation: AllContacts * FractionSusceptible
------Units: Person/Month

Just to emphasize the above we should really stick to this and not use anything like a=b as this gets confusing when writing a specification (even though the meaning is obvious).

3. That following the format of first presenting the conceptual format then the encoding should be followed for both computational and visual/interactive components.

4. That writing up the conceptual computational component should use at least part of Magne's suggested structure - probably something like Motivation(Pragmatic), Range of what can be expressed(Conceptual/Semantic and Syntactic) and Syntax Details (Lexical). There will always be a bit of blurring as we present material at one level using examples from later levels (can't really talk about Range of expression without example equations and so on).

Bob Eberlein

Magne Myrtveit
Posts: 57
Joined: Mon Jan 12, 2009 6:52 am

Re: SMILE and XMILE

Post by Magne Myrtveit » Tue Aug 27, 2013 1:31 am

Hi Bob,

Yes, indentation is a nice way to illustrate nesting / containment.
Robert Eberlein wrote: Model: WordOfMouth
---Variable: FruitfulContacts
------Equation: AllContacts * FractionSusceptible
------Units: Person/Month
Did you at all consider the alternative ways I presented in §4.5.1.1 - 3 of http://www.myrtveit.com/papers/A_framew ... models.pdf. In this form, your example becomes:
  • model WordOfMouth {
    • var FruitfulContacts {
      • def AllContacts * FractionSusceptible
        type Person/Month
      }
    }
The units property should be optional (why do you use plural?), and it should be changed to type in order to open up for variables belonging to other domains than numbers. See my answer to Thomas Fiddaman here: viewtopic.php?f=4&t=323&start=40#p1932

If we put the type (units) information inside the definition property (which I recommend: the right-hand-side of a variable should fully define it), we can use the "property perspective" described in §4.5.1.2:
  • def {
    • model WordOfMouth {
      • var FruitfulContacts = AllContacts * FractionSusceptible as Person/Month
      }
    }
The above format is a more compact syntax for representing models with nested structures than the "object perspective" used in your example and in §4.5.1.1.

Best regards,
Magne

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest