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] initial draft of container schema chapter & items for discussion

Hi Bobby,

It is chapter 2.  However, I am noticing that neither Chapter 2 nor Chapter 5 are using the templates that are set up in SVN.  The OASIS style start of both chapters is already there at the top level.  For chapter 2, the name is:


It must be in this format and should be in this document.

For chapter 5, it is:


If there is any question, the master file, xmile-v1.0-combine-parts-wd01.doc will direct you to the right place.

Regarding simulation specs, we can talk about it at the meeting, but I disagree that they should be in the root model.  The typical usage is one sim specs for everything, so it should be outside at the global level.  This is then inherited by all models just like styles.

Regarding x and y, that was intentional.  Either you have an x and y, which is the center, or you have a top (y), left (x), width and height (the typical specification for a rectangle - center x, y with a width and height is both unusual and very unintuitive).  I do not expect hand editing of display positions to be a typical use case, so there should be no problem.


On Tue, Nov 12, 2013 at 9:55 AM, Mr. Robert Powers <bpowers@iseesystems.com> wrote:
I believe the chapter number is 2, but maybe its 3?

Also, I have 2 additional items to discuss at the meeting:

1 - Will and I think <sim_specs> should be removed as a top-level tag in <xmile> and simply be an attribute of the <model>.  When simulating, the <sim_specs> of the root model would be used, and optionally <sim_specs> specified on modules's models would be honored.  This seems like the cleanest approach to us.

2 - Currently the x & y attributes of stocks have different meanings when width & height are specified.  Without an explicit width/height, x & y refer to the center of the ent, but with width/height specified, x & y refer to the top left corner of the ent.  This is unintuitive, and would make hand-editing a stock display tag a surprising process.  I propose having x/y on all ents refer to the center of the symbol, which allows a more graceful handling of width/height modifications and style cascading.

See you at the meeting.


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