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

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.



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?  



  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.



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.

   <stock name="Pop"/>
   <flow name = "Births/>
      <element basedOn="Pop"/>
      <element basedOn="Births"/>
      <element withName="Not yet in 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.



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.



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.



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:

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:

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