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] Very rough draft of section 5: Display and interface structure


Can we divide our first release into point milestones and start labeling and voting on each stage of standards development so that version 1 is built on version .9 which itself is a result of version .8 a few weeks prior and so on.

Regards,

Steve


  From: Billy Schoenberg [bschoenberg@iseesystems.com]
  Sent: 10/09/2013 10:09 AM AST
  To: Bob Eberlein <bob@astutesd.com>
  Cc: xmile <xmile@lists.oasis-open.org>
  Subject: Re: [xmile] Very rough draft of section 5: Display and interface structure


Hi,

Bob -- you are correct my intent was to limit the set of shapes supported.

At the same time though I do agree with Bobby in principal that limiting the visualization of the language to be consistent across models is a good thing.  Now with that said I see Bob's point in being too prescriptive.  I think the way we balance these two approaches is by setting up the following 3 rules:

1. All shape tags written to the file are suggestions
2. A stock may not be represented using a circle
3. An aux may not be represented using a rectangle -- expect if the equation contains a builtin which contains a level

I too look forward to the discussion on this (and defaults etc) tomorrow!

Billy




On Tue, Oct 8, 2013 at 1:42 PM, Bob Eberlein <bob@astutesd.com> wrote:
Hi Bobby,

I read Billy's reply to mean that there should be a defined set of shapes supported, and not an allowance for anything possible.

You raise the more difficult question of how much, and in what manner, do we restrict the allowed shapes. For example, we could say that <stock> can only show up with a Rectangle shape, <rate> has to be a valve of some form, and <aux> can be nothing, a circle or a diamond. I think that captures the bulk of diagrams that would be recognizable as System Dynamics work, unless the model uses smooths or delays. (Something like a=SMTH1(b,t) is really a level and ought to be allowed a box - but would be an <aux> given the language definition.)

I personally, especially because of the last issue, lean toward making the form of _expression_ flexible and depending on either the implementation, or the model creator, to use that flexibility judiciously. I worry that getting to prescriptive about diagram form (to accommodate smooths and whatnot) will unnecessarily complicate the spec and any conforming implementations. I also don't want a spec that needs to be extended to be at all useable by many implementations. I think we are allowed in the spec to issue guidelines on the appropriate way to use that flexibility, and this is the most effective way to discourage the creation of hobgoblin looking models.

I think this is a good topic for further discussion on Thursday.

                   Bob Eberlein





On 10/8/2013 12:29 PM, Bobby Powers wrote:
Hey Bob,

I think I fall onto Billy's side of this as well.  To me, one of the really powerful things about system dynamics is that it is a common language for approaching systems modeling.  Once you know the language of stock and flow diagrams - you can generally understand the approach being taken in a wide range of subjects.  There are some differences between current modeling tools (along with classic hand-drawn diagrams in Industrial Dynamics), but its pretty superficial.  I would be concerned about allowing auxiliaries to look like stocks (squares), or flows looking like connectors - the more variety with how individual items look (which isn't to say how different vendors display things - but with how individual elements are displayed), the less confident you can be that you understand the high level structure at a glance.

yours,
Bobby 


On Fri, Oct 4, 2013 at 10:32 AM, Billy Schoenberg <bschoenberg@iseesystems.com> wrote:
Hey,

I think the way we may address something like that is with an attribute on the display tag like 'shape' (I'm not sure of the proper tag name) but 'shape' could take the value NAME_ONLY, CIRCLE, SQUARE etc.  

My point is by keeping the shape based on an enum we do not all end up implementing a drawing program.

BIlly


On Fri, Oct 4, 2013 at 9:44 AM, Bob Eberlein <bob@astutesd.com> wrote:
Just a comment on this. The model equations are separate from the Views/View (Displays/Display) so really the question is how much variation can there be in the display representation of any given object. Sticking largely to the current specification, but becoming a little more flexible on the shapes of objects will make the whole display representation pretty flexible.

For example, Auxiliaries might default to a circle, but also be represented by diamonds, squares, triangles, hexagons or no shape but just the words. One tag actually adds a lot of variability in appearance.

By taking what is there and adding in characteristics in this way I think we can make the current spec encompass most models in use. It will still likely be true that the fallback appearance, for implementations not supporting much variety, will be Stella models, but that seems like something we can live with.

                Bob Eberlein



On 9/30/2013 10:03 AM, Bobby Powers wrote:
Hi Steve,

I like where your head is at, and I think we made some great steps in the last meeting towards somewhat abstracting <view>s, but specifying how to define and use new vocabularies of visual objects would expand the scope too much for v1.  I'm also a firm believer in having concrete examples - I would want several example model files with alternate vocabularies so that we can figure out exactly what needs to be refactored/abstracted in the representation/language.  That's my take at least.

Thanks!

yours,
Bobby


On Sat, Sep 28, 2013 at 2:09 AM, Steven Adler <adler1@us.ibm.com> wrote:

I like this thread. Can we go one step further than CLD simulation and make it possible for developers to choose alternative representational objects to model and simulate with XMILE vocabularies so as to separate the logical descriptions of functions from their symbolic representations?  

Regards,

Steve


  From: Karim Chichakly [kchichakly@iseesystems.com]
  Sent: 09/24/2013 11:01 AM AST
  To: xmile@lists.oasis-open.org
  Subject: Re: [xmile] Very rough draft of section 5: Display and interface structure


Hi Billy and Bob,

1) I agree with Bob that CLDs can be simulated and therefore are not a separate thing - only the representation is different.
2) That naturally leads to the agreement that we need to support alternate representations of the same simulation objects.  However, that can also be done by linking to existing variables in the same way that ghosts do and as Billy suggested.
3) The fact that the display information is with the <stock> and <flow> does not preclude an alternate representation in the display section.  All it says is there is one main representation of that structure and this is what it is.  I really believe that keeping the display tag with the entity makes it easier to read for both humans and programs, e.g., scripts (without it, you have to always build cross-references to do anything).

As for using tags in the spec sections, I think Billy's points are valid, but I also do like the ease of reading of Bob's method.  We should talk about this today.

Best,

Karim


On Tue, Sep 24, 2013 at 9:05 AM, Bob Eberlein <bob@astutesd.com> wrote:

Hi Billy,

First, there is no reason that a causal loop diagram can't be simulated - I used to build models this way all the time though the pedagogy is questionable.

An example of including the same definitional structure in two places is pasted below. Here the interventions, which compute out to effects, are defined elsewhere but repeated here to emphasize the mechanism of action. I also include some key outputs and their most closely associated input to talk to the sources of behavior.

Hope that's helpful.

                     Bob Eberlein


On 9/24/2013 8:46 AM, Billy Schoenberg wrote:
Hi Bob,

Lets definitely discuss the hierarchy of inclusion with the group.  At the moment I still feel like we want to keep them as XML because this spec is after all based on XML and ultimately this spec will have no meaning if you do not understand the basic structure of XML.  At the same time though I definitely agree with you about how XML makes those "diagrams" harder to read and we want to be as easy to read as possible.

As for having multiple displays for a single variable (lets separate that from the placement of that <display> tag) I can see what you are driving towards.  I definitely agree with you that we need a mechanism for linking variables in a CLD to their simulation counterparts.  I think for CLDs which are not simulatable we want to use a named based link back to model entities so for instance you may have the following CLD based on the following model.

<model>
   <stock name="Pop"/>
   <flow name = "Births/>
   <cld>
      <element basedOn="Pop"/>
      <element basedOn="Births"/>
      <element withName="Not yet in model"/>
   </cld>
</model>

As for the placement of the <display> tag for an entities representation in the stock and flow diagram I think it may be best to move it from inside of the <stock> or <aux> etc tag to be directly a child of the stock and flow diagram's <display> tag.  I think that will more easily allow Ventana to implement the spec re: Vensim sectors (which is a whole other discussion re: the <group> tag) and I think it will make the files more easy to parse.  I think we solve this after we solve the above questions (re: CLD, and Vensim sectors)

As for your aging chain example do you have an example that you can send me?  I would love to see that in reality because at the moment I still have a hard time seeing exactly what you mean.

Best,

Billy



On Sun, Sep 22, 2013 at 10:07 AM, Bob Eberlein <bob@astutesd.com> wrote:
Hi Billy,

Your point on using the tags is well taken. There is no point in introducing different monikers in the two sections. I will update the language spec section to follow this pattern.

As far as the hierarchy of inclusion goes, however, I still find indented lists to be far easier to understand quickly than looking at XML. In fact, when I look at XML I usually just hope that the indentation used is reflecting what I think it is and ignore closing tags and the "actual" structure of the material. So, while XML closely reflects what will be in the final stored models, I think it hampers understanding at the conceptual stage.

On the second point I definitely do mean the diagrammatic representation of the models. One thing I often do in teaching is to create one view of a model using stock and flow and another using causal loops. This is an effective way of showing how feedback manifests visually in the two different forms and how it can seem hidden in the stock and flow form. Another common use for repetitions of structure is the inclusion of more than just a ghost or shadow as input in order to clarify structure. Often the stocks in an aging chain from one part of the model when used connected together in another part make it easier to understand the other part.

The goal in this specification, from my perspective as a representative of the System Dynamics Society, is to be able to capture the vast majority of models in use in our field. Holding to a single definitional visual representation of model variables would definitely thwart that. That still leaves the question of whether we include two distinct methods for display representations, or always separate it from the variable definitions.

                                             Bob Eberlein



On 9/20/2013 9:43 AM, Billy Schoenberg wrote:
Hi Bob,

Thanks for the comment:

1. Format:  I believe that in this case it makes sense to use XML in the conceptual section.  The reason being is that I spent a lot of time talking about where tags go in the tag hierarchy and how the positions of those tags affect their meaning.  The other portion of the conceptual section was dealing with commonly re-used XMILE objects/tags.  So in order to have them be fully specified (and easily referred to later) I felt it was best to include the actual tag.

The reason I did it like this is that I imagine chapter 6 the actual specification will go into great depth about each object (which will be composed of the objects discussed in chapter 5) and I felt it would be much easier to refer to the objects back in chapter 5 then it would be to re-introduce them again in chapter 6 and end up splitting up their discussion

2. Substance: I think I have to be misunderstanding you here: "Since the intention is to allow multiple display representations for any given variable" -- What I hear when you say this is that we want the ability to have multiple symbols (box, arrow, etc etc) representations for a single variable in a model (aliases would be the only case of this and will be covered separately in chapter 6 when we describe each XMILE display object).  That is something I strongly disagree with -- but if you explain why you think its a good idea I can be convinced otherwise.  What I hope you mean is that we want the ability to have different formats, scales, ranges for any single variable.  With that I would agree 100%, and my response would be that the display tag only deals with the symbols, not the number formatting, scales or ranges.

Best,

Billy


On Thu, Sep 19, 2013 at 8:31 AM, Bob Eberlein <bob@astutesd.com> wrote:
Hi Billy,

Thanks for putting this together. I have only gone through this superficially at this point, but it raises two big issue, one of format and one of substance. Both are worth discussing further in the group.

On format I was envisioning that the conceptual sections would stay away from XML and instead use something like the attached - basically an indented list. I find this easier to read and therefore more effective at conveying the logical structure of the model and layout representations. I would like to hear others opinions on this.

The substantive issue is related to the display, something I raised in my earlier notes. Since the intention is to allow multiple display representations for any given variable it seems that including display information inside of the variable definition and parallel to the equations, units and comments definition is undesirable as there will be a well defined way to do this inside a broader display definition. Again I would like to here others' opinions on this.

                                     Bob Eberlein

On 9/12/2013 4:11 PM, Billy Schoenberg wrote:
Hello Folks,

As promised I have put together the 'very rough draft' of section 5: Display and interface structure.

I have not applied any styles etc to this draft as I felt it was a distraction at this point.  I will be happy to apply any OASIS styles etc once Karim creates the document that we discussed a few days ago based off of the document that OASIS has provided us.

In this section I tried to cover all of the broad underlying assumptions behind all visual XMILE objects and I tried to specify all of the commonly used objects/concepts in the display/interface specification.

Please feel free to share any comments/suggestions via e-mail.  At the moment I would please ask that no direct edits to the document are performed until it can be placed in the proper place in version control.  I say this because I am not prepared to merge in a bunch of changes.

Best,

Billy



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php













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