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] 1.5.2 Non-Apply-to-All Array


My suggestion is that for interface stuff, we make almost everything per parent.    Isn't that how it works now?  The <view> tag doesn't have a child <array>.

WILL


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

I like the version with the <element> better too.

I might be able to shed some insight into Rob's though process.  I think he was having a hard time determining if an entity was apply to all or not without using the <array> tag.  I think this concern is not valid.  I also think Rob wanted to be able to re-use the same tag reader for a non arrayed entity as he used for each element.

This brings up another related point of what things are shared per element vs. per array parent.  How does this relate to posters, number formats, scales etc.  (I think all of the things I listed are per element, only units, inflows, outflows, non_negative etc are per array parent)

Billy

 


On Mon, Jun 2, 2014 at 12:55 PM, Bobby Powers <bobbypowers@gmail.com> wrote:
Hi Karim, this sounds good - <element> makes sense since there are other attributes that may also change per subscript.

yours,
Bobby


On Mon, Jun 2, 2014 at 12:30 PM, Karim Chichakly <kchichakly@iseesystems.com> wrote:
Bobby, I too like the concept.  It is much cleaner, but it is only a starting place.  There are many separate attributes per element so you really can't just tag <eqn>.  You need to develop a new tag to group each element's attributes together (perhaps <element subscript="...">).  The original specification of this did use <element> like this, but there were parsing problems that AFAIK were tied to the implementation of this.  I wish I could remember the exact issue that led to the change you see today.  [I did ask Rob and he remembered it was difficult to implement read the other way, but did not remember why.  He thought it was because he needed to know it was an array from the very beginning rather than being surprised by an element tag in the middle.]

In any case, if we all like this better, I propose we go back to that older spec, which was:

<aux name="not_apply_to_all">
  <dimensions>
    <dim name="X"/>
    <dim name="Y"/>
  </dimensions>
  <element subscript="1,1">
    <eqn>TIME</eqn>
  <element>
  <element subscript="1,2">
    <eqn>2*TIME</eqn>
  <element>
  <element subscript="2,1">
    <eqn>TIME^2</eqn>
  </element>
  <element subscript="2,2">
    <eqn subscript="2,2">2*TIME^2</eqn>
  </element>
  <units>Euros</units>
</aux>

Karim



On Mon, Jun 2, 2014 at 12:19 PM, Will Glass-Husain <wglass@forio.com> wrote:
Bobby,

I prefer your syntax -- it's much clearer and concise.   If you are hand-editing models it reducing the likelihood of errors since there is less duplication.

This seems an important proposal to me, and feasible to include.

WILL


On Mon, Jun 2, 2014 at 8:28 AM, Bobby Powers <bobbypowers@gmail.com> wrote:
Hello,

I think this section needs work, I would not like to see the current specification approved with two distinct ways to create arrays.

To review, arrays with a singe equation for all dimensions (apply to all) is created like this:

<aux name="distance">
  <dimensions>
    <dim name="X"/>
    <dim name="Y"/>
  </dimensions>
  <eqn>SQRT(X^2 + Y^2)</eqn>
  <units>kilometers</units>
</aux>

And one with different equations for different dimensions is created like this:

<array name="not_apply_to_all">
  <dimensions>
    <dim name="X"/>
    <dim name="X"/>
  </dimensions>
  <aux subscript="1,1">
    <eqn>TIME</eqn>
  </aux>
  <aux subscript="1,2">
    <eqn>2*TIME</eqn>
  </aux>
  <aux subscript="2,1">
    <eqn>TIME^2</eqn>
  </aux>
  <aux subscript="2,2">
    <eqn>2*TIME^2</eqn>
  </aux>
  <units>Euros</units>
</array>

Having a top-level array tag is unintuitive to me.  Apply-to-all gets it right - the most important piece of information about a variable is its type <aux>, not that it is an array.  Changing the outermost tag from <aux> to <array> when changing the variable from an apply-to-all array to a non-apply-to-all array doesn't make sense from a spec standpoint - you don't have multiple variables, you have multiple equations for the same variable.

I suggest changing this to simply allowing the subscript attribute on the <eqn> tag:

<aux name="not_apply_to_all">
  <dimensions>
    <dim name="X"/>
    <dim name="Y"/>
  </dimensions>
  <eqn subscript="1,1">TIME</eqn>
  <eqn subscript="1,2">2*TIME</eqn>
  <eqn subscript="2,1">TIME^2</eqn>
  <eqn subscript="2,2">2*TIME^2</eqn>
  <units>Euros</units>
</aux>

A sidenote - the above example from the spec is not dimensionally consistent - it has a variable with equation TIME and units Euros.  Do we want/need to edit the spec for dimensional consistency in examples?

yours,
Bobby



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