Forums

OK. I can see that a bounding box really makes sense since the tools
might want to have the canvas larger then the layout of the objects
would require.
I just put a new version of the proposal on the webpage (
http://projects.eml.org/bcb/sbml/ ) that includes the information about
pt being the default unit and the bounding box for the layout object.
At least the width and height attribute of the bounding box are now
required with the depth attribute being optional and defaulting to 0.0.

So what about the rest of the proposal. Does everything else make
sense, or are there more things that need to be changed or improved?

Ralph


On Donnerstag, September 11, 2003, at 06:10 Uhr, Wagner,John wrote:

> Yeah. There's that too. :)
>
> It is at least optional always in the sense that some tools
> will probably ignore it. And, since it's easy to compute
> a bounding box if you need it, I'd expect those tools that
> depend on it to be able to compute it if needed.
>
> If people like the idea of making it mandatory, I'm all
> for it. I was thinking that if it is optional, more people
> might be willing to accept it.
>
> John
>
> -----Original Message-----
> From: Herbert Sauro [mailto:Herbert_Sauro@kgi.edu]
> Sent: Thu 9/11/2003 12:04 AM
> To: Wagner,John; Herbert M. Sauro; Ralph Gauges
> Cc: sbml-discuss@caltech.edu
> Subject: RE: [sbml-discuss] DWG: Revised Proposal
>
>
>
> If the canvas size is optional, and some of us don't write it out,
> what happens to those tools that depend on it? Perhaps it should not
> be optional?
>
> Herbert
>
> -----Original Message-----
> From: Wagner,John [mailto:JWagner@nso.uchc.edu]
> Sent: Wed 9/10/2003 7:43 PM
> To: Herbert M. Sauro; Ralph Gauges
> Cc: sbml-discuss@caltech.edu
> Subject: RE: [sbml-discuss] DWG: Revised Proposal
>
>
>
> I can imagine people actually wanting to store the overall
> size of
> a layout. Some tools may have an "auto-size" canvase, whereas
> other tools might use an explicitly-sized canvas. I see no
> harm
> in adding these as optional attributes, with the default
> being to
> determine the size based upon the contents inside. JMHO.
>
> John
>
> -----Original Message-----
> From: owner-sbml-discuss@its.caltech.edu on behalf of
> Herbert M. Sauro
> Sent: Wed 9/10/2003 2:52 PM
> To: Ralph Gauges
> Cc: 'sbml-discuss@caltech.edu '
> Subject: Re: [sbml-discuss] DWG: Revised Proposal
>
>
>
>
>
> That's good news. I don't think we need information
> on the overall
> dimensions of the diagram, simply the units for
> coordinates and fonts.
> 72dpi sounds correct, font infomation I feel should
> be in pts since one pt
> equals 1/72 inch.
>
> Herbert
>
>
> On Wed, 10 Sep 2003, Ralph Gauges wrote:
>
> > I just scanned over the document and you are right,
> obviously we forgot
> > to put the consensus we had reach in the discussion
> on this list into
> > writing. Sorry, I was under the impression that I
> put it in already. I
> > will add this at once.
> > As far as I remember it was agreed upon in this
> list that the default
> > unit of the layout would be a pt which is 1/72 inch.
> > The dimension of the whole diagram can then be
> easily calculated from
> > the components. Or do you think we would need to
> specify the dimension
> > of the diagram somewhere? We actually thought that
> this information was
> > not necessary because it could be deduced while
> reading in the objects.
> >
> > Thanks for the feedback
> >
> > Ralph
> >
> > On Dienstag, September 9, 2003, at 07:42 Uhr,
> Herbert M. Sauro wrote:
> >
> > > Ralph, the main reason why I was going to look at
> Jonathon's proposal
> > > first was because he has some dimensioning
> information which means I
> > > know
> > > what size to draw the diagram. As far as I can
> tell your proposal does
> > > not
> > > have this information, are there even any default
> dimensions? As a
> > > result I am
> > > unable use your proposal as it stands. If I have
> a mistaken view here
> > > do
> > > please correct me, and if you have suggestions on
> sizing the layout
> > > expressed in EML, I'd be happy to listen. I think
> Jonathon has yet to
> > > specify the font sizing, at the momemt the
> proposal suggests using the
> > > unitsin the diagram, not sure if this is a good
> idea as traditionally
> > > font
> > > info is expressed in pts. Currenlty even
> Jonathon's proposal will not
> > > be
> > > easy to use. So there appear to be issues with
> both. In
> > > Jdesigner I use pts to indicate font sizes and
> dimensions are set by
> > > default to by 92dpi. I have a version 2
> (unpublished) which adds
> > > further
> > > material but this was done before the DWG got
> going.
> > >
> > > Herbert
> > >
> > >
> > > On Fri, 5 Sep 2003, Ralph Gauges wrote:
> > >
> > >> Sorry for the delay, but with everybody on
> vacation, this has been
> > >> lying around for some time.
> > >> In case anybody is wondering. This is the next
> version of a proposal
> > >> for a layout extension to SBML2.
> > >>
> > >> This version includes some important new
> features like the possibility
> > >> to group several layout objects and the
> possibility to specify edges
> > >> to
> > >> denote relations.
> > >> We also incorporated the suggestions we got from
> the discussion. E.g.
> > >> the syntax is now more SBML like as references
> attributes are called
> > >> after the thing that is being referenced. So the
> reference attribute
> > >> to
> > >> the SBML compartment id in the compartmentGlyph
> is now called
> > >> compartment. We also got rid of all the
> ...GR(s), they are now called
> > >> ...Glyph(s).
> > >> There are some smaller changes (See "List of
> Changes" in the
> > >> document).
> > >>
> > >> We tried to come up with layout problems that
> can not be solved with
> > >> this proposal and so far we have not been able
> to come up with any. So
> > >> if you know of some layout that can not be
> specified in terms of this
> > >> proposal, please let us know.
> > >>
> > >> There has been a new proposal for a layout
> extension by Jonathan Webb
> > >> a
> > >> few days ago. We would have preferred for
> Jonathan to give us some
> > >> feedback as to what he didn't like about the
> proposal that was already
> > >> there and so help to speed things up, because
> this is what a
> > >> discussion
> > >> list is for and this is the reason why we made
> the proposal to the
> > >> discussion list in the first place.
> > >> Looking at his proposal we think that it is
> missing some things
> > >> that our proposal already has and that we think
> are important.
> > >>
> > >> 1) Jonathan himself stated in his document that
> it was not a full 3D
> > >> specification, but rather 2.5D. But with the
> inclusion of geometry
> > >> information on compartments in upcoming versions
> of SBML, we think
> > >> that
> > >> the proposal should include the possibility to
> render objects in 3D.
> > >>
> > >> 2) Jonathan's proposal takes color
> specifications from HTML and limits
> > >> colors to RGB instead of RGBA. Partly
> transparent objects might really
> > >> be useful when working with 2.5D or 3D layouts,
> so colors should
> > >> really
> > >> have an alpha channel.
> > >>
> > >> 3) As has been noted in earlier discussions on
> this list, there was an
> > >> agreement that metaids should not be used to
> reference objects.
> > >> Jonathan
> > >> does this in his edge.
> > >>
> > >> 4) In the edge object of his proposal, Jonathan
> references the species
> > >> reference of the model for the edge, but since a
> species can be
> > >> represented by several graphical objects in a
> layout, there is no easy
> > >> way to
> > >> find out which of possibly several species
> glyphs should
> > >> be connected to a given reaction. He tries to
> circumvent this problem
> > >> by identifying the species glyphs by coordinates
> which will fail if to
> > >> species glyphs share the same coordinates.
> > >>
> > >>
> > >> We are aware of the fact that so far our
> proposal only includes
> > >> layout
> > >> information since we wanted to separate the
> layout information from
> > >> the
> > >> render information. So in order to get an
> agreement on the layout
> > >> part,
> > >> we did not do much work on the render part yet.
> As we took from the
> > >> discussion, there was some agreement as to that
> it was a good idea to
> > >> separate render and layout information. As
> stated above, we tried to
> > >> find layout examples that could not be
> implemented with this proposal
> > >> and so far we found none. If someone finds such
> an example we would be
> > >> glad to hear of it so we could make the
> necessary changes. We also
> > >> would very much like more feedback on what else
> people are missing
> > >> from
> > >> the proposal since this is the only way we can
> reach an agreement.
> > >> Mails that only state that something is missing
> without ever
> > >> elaborating on this are therefore not very
> helpful and won't help in
> > >> reaching an agreement.
> > >> We feel that this proposal has come a long way
> and we thank all the
> > >> people that participated in the discussion. We
> don't know, if this new
> > >> proposal has everything that people expect of
> it, but as far as we are
> > >> concerned, we would be ready to move on to
> getting the specification
> > >> for the render information written down. Now if
> the majority of people
> > >> on this list feel that they would rather go with
> Jonathan's proposal
> > >> and work from there, we would appreciate it if
> you let us know as soon
> > >> as possible.
> > >>
> > >> Ralph
> > >>
> > >
> >
>
>
>
>
>
>
>
>
>