Re: [xmile-comment] spec comments

Thanks Bobby.

I think your comments on includes are spot-on, it's a very tricky feature that needs to implemented carefully. I'm more concerned though that you mention that as far as you know, no vendor has implemented them yet.

From my understanding, includes are a mandatory part of the spec required for base conformance (section 7.2.1 bullet 10).

Looking at the XMILE email logs I see that three vendors have submitted conformance statements over the past year:

* isee systems [https://lists.oasis-open.org/archives/xmile/201411/msg00002.html]

* transentis [https://lists.oasis-open.org/archives/xmile-comment/201411/msg00002.html]

* sdxchange [https://lists.oasis-open.org/archives/xmile-comment/201507/msg00000.html]

I've cc'ed the authors of each of the statements on this email. Could they please highlight which sections of the spec they have currently implemented and confirm what parts of the conformance clauses in 7.2 and 7.3 they currently meet?

Just doing a quick look around (this was a quick look so I may very well be wrong on some of these items, please correct me if I am):

* it looks like Transentis' tool also doesn't support things like the RK4 algorithm (required by conformance clause 7.3.1 bullet 3) or some of the random number functions (required by conformance clause 7.3.1 bullet 4);

* the sdxchange product is a transpiler targeting XMILE from dynamo, which is very useful but means it could be fully compliant while only implementing a fraction of the spec required for base level conformance. This means there is a potential for a lot of the base spec to not be tested (like includes, or the simulation algorithms).

* I don't own the Stella so can't test or comment on it.

I am concerned if things are in the spec that aren't fully implemented and tested by multiple parties, we risk enshrining things like the security and usability issues Bobby raises for the includes (not to mention the potential for simple incompatibilities). Again, I recommend cutting all optional sections from the spec and adding more specification and detail to the required sections (e.g. precise definition of the simulation algorithms).

Cheers, Scott

On Tue, Oct 13, 2015 at 6:58 PM, Bobby Powers <bobbypowers@gmail.com> wrote:

In general, I agree with Scott's comments. I would prefer the spec focus on the simulation and display of stock and flow diagrams. With that said, I have a number of specific comments:

Section 2.2:

Model caption should be removed. In general, there is a mix of singular and plural, which could be standardized.

Section 2.3:

Save step is missing from the sim_specs object. This is used extensively by Vensim models, and is also implemented in other SD software (at the least my libsd and sd.js projects).

Section 2.11:

I have a lot of worries around include files. The main worry, is that this part of the spec has not been implemented by any Vendor, AFAICT. A second major worry is that the spec is silent on HTTP vs HTTPS. As macros are designed to be turing complete, implementations that include files referenced by http URLs could be subject to man in the middle attacks and arbitrary code execution. A more immediate consequence could be software requesting a URL, getting a 200 OK response, but having the content be a HTTP page with login information about the current WiFi network.

Additionally, I propose that resources provided by vendors at HTTP + HTTPS URLs MUST enable CORS so that this content is available to web pages without a proxy. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS and http://enable-cors.org/ for more information.

Section 3.2.2 Identifiers:

Scott suggested a formal grammar, which I think would help here. I suggest that 'qualified names' are a specific case of identifier, and that to allow that identifiers should be amended to allow periods ('.'). I.e., isee.utils.find and hares.population should both be parsed as single identifiers ("isee.utils.find" and "hares.population").

Section 4.4 Auxiliaries:
Flow concept: flow_concept="…" with true/false, which is true if the auxiliary represents a flow concept (default: false). Besides documenting that the variable is conceptually a flow, this affects how values are reported under certain integration methods and in tables.
This should be removed (preferrable - I believe it is isee specific), or expanded. _how_ does this change how values are reported? Under what integration methods? How does this impact tables?

Section 5.1:

This section lists page_width, page_height, page_sequence, and page_orientation as required. This feels very isee-specific - most SD software I can think of doesn't take the printed-page size to be a fundamental property of a diagram.

Section 6.1.6:

I literally spent days implementing connector angle. Here is an example:

Aux A is centered at 20, 20.
Aux B is centered at 100, 100.
I have a straight line connector from A -> B.
What is the angle (in degrees) between A and B?
easy:

atan((100-20)/(100-20))*180/pi
(45)

Unfortunately, the answer is 315. Unfortunately, the coordinate space of XMILE objects has its origin in the upper left, while connector angles are specified to behave as if the origin was in the bottom left. Additionally, the domain of the connector angle is between 0 and 360, but the common trig functions have a domain of -180 to 180.

I suggest that connectors increase in angle in a clockwise fashion, and have the domain -180 to 180.

Looking forward to hearing your thoughts.

yours,
Bobby

xmile-comment message