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] modules


Let me state your point another way Steve: "assertions that other vendors, who can't be consulted and are not here, will like the spec as is, are unvalidated assertions and can't be treated as facts".  

I agree with Will about this being something to be brought up in Delft & on our next meeting.

yours,
Bobby


On Mon, Jun 2, 2014 at 11:58 AM, Steven Adler <adler1@us.ibm.com> wrote:

"Simple" is not good enough as a reason. Assertions that other vendors, who can't be consulted and are not here, will not like the spec as is, are unvalidated assertions and can't be treated as facts.

If there is a demonstrable business benefit for doing this now I'm for it. If not, let's pick it up in v2.

Regards,

Steve


  From: Bobby Powers [bobbypowers@gmail.com]
  Sent: 06/02/2014 11:52 AM AST


  To: Steven Adler
  Cc: Karim Chichakly <kchichakly@iseesystems.com>; Will Glass-Husain <wglass@forio.com>; xmile <xmile@lists.oasis-open.org>
  Subject: Re: [xmile] modules


Hi Steve,

Perfect and simple are not the same thing.  The simpler the specification is, the easier it will be to get people to adopt it, and (maybe more importantly), the easier it will be to iterate toward perfect later.  Good enough should mean simple - not ill-defined.

yours,
Bobby


On Mon, Jun 2, 2014 at 11:47 AM, Steven Adler <adler1@us.ibm.com> wrote:

No. We should strive to publish a spec that is good enough and perfect it later.

Regards,

Steve


  From: Bobby Powers [bobbypowers@gmail.com]
  Sent: 06/02/2014 11:44 AM AST


  To: Steven Adler
  Cc: Karim Chichakly <kchichakly@iseesystems.com>; Will Glass-Husain <wglass@forio.com>; xmile <xmile@lists.oasis-open.org>
  Subject: Re: [xmile] modules


Because a more complex spec is harder to adopt than a simple spec.  If we want more consultation (people implementing it), we should strive towards a simpler artifact.

yours,
Bobby


On Mon, Jun 2, 2014 at 11:37 AM, Steven Adler <adler1@us.ibm.com> wrote:

If the issues are not yet concrete enough for consultation why should we change them in version 1.0 of the spec?  Can't they wait for v2?

Regards,

Steve


  From: Bobby Powers [bobbypowers@gmail.com]
  Sent: 06/02/2014 11:16 AM AST
  To: Steven Adler
  Cc: Karim Chichakly <kchichakly@iseesystems.com>; Will Glass-Husain <wglass@forio.com>; xmile <xmile@lists.oasis-open.org>
  Subject: Re: [xmile] modules


Hi Steve,

Reaching out is a great idea, but I don't know how helpful it will be.  It is hard to figure out what the concrete issues are until people actually write the code to save and read their models in the specified format.

yours,
Bobby


On Mon, Jun 2, 2014 at 11:06 AM, Steven Adler <adler1@us.ibm.com> wrote:

Why not ask the other vendors what they think about this?  They may not be TC members but we can still consult them and maybe through consultation they will see a new need to join.

Would that make sense?

Regards,

Steve


  From: Bobby Powers [bobbypowers@gmail.com]
  Sent: 06/02/2014 11:03 AM AST
  To: Karim Chichakly <kchichakly@iseesystems.com>
  Cc: Will Glass-Husain <wglass@forio.com>; xmile <xmile@lists.oasis-open.org>
  Subject: Re: [xmile] modules


Hello,

Thanks for the clarification Karim.  To clarify my position - Ventana, Powersim, Sysdea, and Insight Maker are either not on this TC or are not participating - although I do acknowledge and appreciate the Vensim knowledge Bob brings to the table.  I think it will be better for them to have a _simple_ spec to implement, rather than a complicated one that tries to imagine what they want.  So saying that we require them to use modules in the file format to implement sub-models seems simple and nice, and they can choose to create in-memory datastructures in their programs however they see fit.  As far as I know (and this may have changed as Will works on the XSD), I have done the only implementation of significant parts of the spec outside of isee, and the only implementation of XMILE based off the specification ( free software: https://github.com/sdlabs/sd.js ).  I think we will be better off as a community with something as simple as possible, and then be willing & ready to quickly iterate upon pain points when other vendors begin implementing the spec, rather than trying to anticipate all of the corner-cases of their needs.

yours,
Bobby



On Mon, Jun 2, 2014 at 10:51 AM, Karim Chichakly <kchichakly@iseesystems.com> wrote:
Hi Will,

Here is a simple example from the draft spec (which got lost in updating, sorry):

<aux name="xyz" access="input">
  
<eqn>STEP(1, 2)</eqn>
  
<of>module.abc</of>
</aux>

<aux name="abc" access="output">
  
<eqn>SINWAVE(5, 4*PI)</eqn>
  
<to>module2.xyz</to>
  
<to>module3.kjc</to>
</aux>

Karim



On Mon, Jun 2, 2014 at 10:42 AM, Will Glass-Husain <wglass@forio.com> wrote:
Can you give an example which uses <of> and <to>?  Reading the spec, I couldn't figure out where they go.

WILL


On Mon, Jun 2, 2014 at 7:39 AM, Karim Chichakly <kchichakly@iseesystems.com> wrote:
Hi Will,

To sum up, no or I would have already dropped it.

It is not obsolete and I did recently update that section - as Bobby pointed out (thank you).  The fact is we do not require people to have a module to use submodels and there is no other way to create the cross-model connections.  There are examples where other vendors could have submodels but not modules.  Bob has brought these up, but maybe some of them are only an artifact of translation.

The other reality is you do not need modules if all you have is two levels.  Everything works perfectly with <of> and <to>, and this is really the case we were trying to support.  I agree it throws a seemingly unnecessary redundancy into the mix, but the goal is to support more vendors, not less.  At some level, we have to decide how restrictive we need to be - vs. what we hope people to do.

Karim


On Mon, Jun 2, 2014 at 10:37 AM, Will Glass-Husain <wglass@forio.com> wrote:
Hi,

To sum up then, we can drop that section and the concept still works?

WILL


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

I may have gotten it wrong with the word 'obsolete' - but that is how I feel.  The spec says it is for packages that support submodels but don't support modules (isee is opposite - it only supports submodels through modules).  I would propose to remove <of> and <to> since we don't have any feedback from vendors with submodules-only, and having 2 ways to do things is more complicated than it needs to be.  I think the spec says it well, too: "There is a reason for two separate mechanisms [<of> and <to>]: If a submodel wants to be re-used, its connections must always be specified above it. As already described, the only solution that works for all cases if to describe those connections in the LCA of the variables [via <connect> tags]. This is not possible with this mechanism..." - section 4.7.4.  So <connect> is more general, and its not clear to me that <of> and <to> are specifically more useful to anyone currently.

yours,
Bobby




On Sun, Jun 1, 2014 at 8:54 PM, Will Glass-Husain <wglass@forio.com> wrote:
Thanks.  Does that mean we can drop section 4.7.4 entirely?   ("Submodel Connections without Modules")

Does the section on submodels still make sense in that case?

I've left this out of the xsd.

WILL


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

<of> and <to> are obsolete and were removed, but the spec was never updated.  of and to created a strange situation where the information necessary to initialize the modules is stored in multiple locations, and creates confusing dependency issues.  The connect tags listed inside a module instantiation are a better way to solve the problem - they are effectively dependency injection through constructor parameters.

It is possible I got some of the details wrong - this happened a while ago.  I'm confident someone will speak up if so :)

yours,
Bobby


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

(apologies for the series of emails -- hopefully not many more).

Regarding modules.  The spec references <of> and <to>.   I can't figure out where these are inserted.   Can anyone explain?

When I make a submodel in iThink, I get something like the following.  (removing display/interface tags).

<?xml version="1.0" encoding="utf-8" ?>
<xmile version="1.0" level="3" xmlns="http://www.systemdynamics.org/XMILE" xmlns:isee="http://iseesystems.com/XMILE">
  <model>
    <module name="Module_1">
      <connect to="price" from=".basePrice" />
      <connect to=".profit" from="revenue" />
    </module>
    <aux name="basePrice">
      <eqn>10</eqn>
    </aux>
    <aux name="profit" access="input">
    </aux>
  </model>
  <model name="Module_1">
    <aux name="price" access="input">
      <eqn>1000</eqn>
    </aux>
    <aux name="revenue" access="output">
      <eqn>price * 10</eqn>
    </aux>
  </model>
</xmile>

This makes sense to me and is captured in the draft xsd file I have.  But (syntactically) where would <of> and <to> go?

best,
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





--
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]