OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xmile message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xmile] model url / event poster


Hey,

I agree with Bobby they should be as children of the variables if they are going to be used in the way I envisioned above.  If we see (for the XMILE spec) a wider use for them AKA being fired for poor performance, going bankrupt etc then in my opinion they should be an interface construct (AKA Forio conditionals).

I think we want to separate out the two uses, runtime errors/warnings from interface control flow.  I think the interface control flow portion should be handled in a later version of the spec.  There is too much thought that is required to be put into that construct to start that process now (11 days before we want to vote on this spec).

As for the runtime errors/warnings maybe that too falls into the same category as above, something nice, but not something required for v1 of the spec, especially considering the thought effort that needs to be put in 11 days before the vote.  Either way here I think posters as currently spec'd need work, and that potentially the easiest way to handle them is to pull them out of v1 and make them vendor specific so as to not create hassle for ourselves in v2 of the spec when we can specify them more clearly.

Billy




On Mon, Jun 2, 2014 at 10:37 AM, Will Glass-Husain <wglass@forio.com> wrote:
I'm on the fence about event posters.

But I do see use cases outside of iThink.

For example, Vensim allows models to stop at arbitrary points by changing the stop time.

And we've built Forio game like simulations in which the game ends early, say if the player is fired for poor performance.   

In both cases, the event poster feature can be used to implement this.

WILL


On Mon, Jun 2, 2014 at 7:31 AM, Bobby Powers <bobbypowers@gmail.com> wrote:
Hi Billy,

Thats good feedback.  Specifically I feel like event posters are inverted in their specification.  If the goal is runtime errors/warnings for variable values, that should be specified on the variable itself.  In fact - it already partially is with <non_negative>.  I don't like having to write code to look in multiple locations for this sort of stuff.  I would suggest that if we want to allow for user errors saying "calculation error, prices can never be negative" that it should live with the variable prices, not separately somewhere else in the file.

I agree that warnings like that are good for the user, but I think we need to firmly limit the scope of the spec if we want it to be in a publishable state sometime soon, and that since there is (in my mind at least) a lot of questions as to how and where runtime warning & errors should be specified, it should be left out of version 1 of the spec.  There would be no impact to isee that I can see, and it would allow us to better discuss it and come to a consensus for version 1.1 or 2 of the spec.

yours,
Bobby


On Mon, Jun 2, 2014 at 10:17 AM, Billy Schoenberg <bschoenberg@iseesystems.com> wrote:
Hi,

I agree on with the use of the <include> tag.

As for posters I think there is some value in including a small subset of the feature.  In particular I think the subset that is worth making core to XMILE the ability for a threshold to be passed (or met) and for the simulation to be stopped (in the case of an error) or paused (in the case of a warning) for a text message to be displayed.

In english, lets imagine a pricing model.  The modeler would specify.  "If price is less then 0, stop the simulation, display message to user saying 'calculation error, prices can never be negative'".  I see it as a way of allowing modeler generated runtime errors/warnings.

I think this is important because it lets the modeler warn users of the simulation when the simulation has exited reasonable bounds of results or may be operating incorrectly.  I think this will help to de-complicate the feature for v1 of the spec (removing the image, videos aspects), while providing useful functionality, while also giving us a base to suggest additions in future versions of the spec.  I still think even this core subset of functionality is an optional feature <uses_events/> in the options tag.

Billy


On Sun, Jun 1, 2014 at 9:14 PM, Will Glass-Husain <wglass@forio.com> wrote:
I agree with you, Bobby for the reasons you listed.

Look forward to any thoughts on this from Karim, Bob, etc.

WILL


On Sun, Jun 1, 2014 at 5:58 PM, Bobby Powers <bobbypowers@gmail.com> wrote:
Hello Will,

I think <include> instead of <model url> is a very nice simplification.

I have said before I that I think event posters should be removed from the spec - they are not a core feature of system dynamics, can be implemented as an isee vendor extension, and then added in a future expanded version of the spec if they're adopted by other vendors.

yours,
Bobby


On Sat, May 31, 2014 at 2:50 PM, Will Glass-Husain <wglass@forio.com> wrote:
Hi,

I'm working through some more details this weekend on the model schema.  More questions.

(1) <model url="">

In <model> I see you can use a URL for model contents.  

I note that the include tag provides the same capability (ability to include models from an external model) and it's more specific (includes the ability to version, etc)..     I propose we drop the "url" attribute from model and instead encourage use of <include>.

The spec reads:

Optional reference to a separate model file for the model contents:  url="" with a URL path. Since the <module> tag can also specify the model file URL, this is only needed for models that do not use modules. However, when the same module is shared in multiple parts of the file, it is better to create one URL reference in a model block, rather than specifying it in the module block.

Comments?

(2) <event_poster>

There is not a complete example for event_poster in the spec.  Is this how it works?  

<event_poster min="0" max="1000000">
  <threshold value="1000" direction="decreasing" repeat="each">
    <event sim_action="message">Your profit is dropping</event>
  </threshold>
  <threshold value="100" direction="decreasing" repeat="once">
    <event sim_action="stop">You are fired!</event>
  </threshold>
</event_poster>


Cheers, WILL
--
William Glass-Husain   /forio  |  +1 (415) 440 7500 x89  |  forio.com





--
William Glass-Husain   /forio  |  +1 (415) 440 7500 x89  |  forio.com






--
William Glass-Husain   /forio  |  +1 (415) 440 7500 x89  |  forio.com




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]