I could imagine two outcomes for the field. The dream is for interchange to attract new business, through safety in numbers, enhanced productivity, etc. The nightmare is for the standard to become captive to a vendor that uses it to bludgeon competitors (imagine gov't RFPs requiring compliance with a convoluted standard).My original MIF proposal aimed at creating a format for interchanging models among software tools, without forcing vendors to change their concepts and feature set. In 1995 this was possible, but since then, significant advances have been made by different vendors, in different directions. The definition of a superset of the most popular SD languages today would become a monster full of partially overlapping and conflicting concepts; extremely expensive to develop and practically impossible to learn.
Therefore, my recommendation to the OASIS committee is the following:
Create a new language / representation for “basic SD” models. It includes only the concepts and features that are needed to teach SD and develop models of general interest. In particular, I suggest that the basic SD supports measurement units and logical values, but probably not arrays and definitely not macros. All vendors should have few problems reading and writing this mini-language.
The design of the “basic SD” language and its companion XML representation should be such that it can be extended to include any of the concepts and features that are part of current SD software, including some of the newcomers where most of the highly needed innovation is to be found.
Each vendor is urged to open up its document format, preferably in an XML based, vendor-specific extension to “basic SD”. This makes it possible for each vendor to implement import from other model formats with a minimal loss of information. I have used this approach by implementing MDL import in Dynaplan Smia. It took me one week to complete. It allows Smia users to import almost any Vensim model without loss of functionality. (As a test, I loaded and run all the models accompanying “Business Dynamics” without any problems). I believe that import of models following the current XMILE specification can be implemented in roughly the same amount of time.
No vendor should be burdened by having its own native standard as the official SD standard. Therefore, XMILE should be reserved either for isee or for the SD society, and the other part should find a new name for its specifications. (Suggestion: isee finds a vendor-specific name for their language and file format).
Instead of boring you more with my own reasoning, I’d like to challenge the advocates of the XMILE standard to make visible their mental models, and even create an SD model, that shows how they expect that XMILE will influence the field and its stakeholders, how the feature set of each vendor is accounted for, what the costs will be and how they can be justified, and what we can expect in return.
To avoid the nightmare variant, I like Magne's idea of a minimal standard that represents the intersection of functionality rather than the union. This will also be quicker to implement, and if the dream works, time to market is important.
Regardless of history, we're OK with the current SMILE/XMILE as a starting point, because it's easy to work with. But perhaps we should be looking at things to exclude from it, or make optional, as well as ways to extend it, and perhaps creating a straightforward way to include <vendor specific> blocks that define things we haven't contemplated.