Forums

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

Attachment: layout2.xsd (Size: 8.91KB, Downloaded 962 time(s))

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

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

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

Looking really good, Ralph. One question...

Your document mentions separating layout and render info
(which I very much like). Obviously, we've not gotten to the
rendering part, at least not yet. But, what is your vision of
how rendering would fit into your scheme? One of the
reasons I ask is, depending on where it fits in, the naming
might not quite make sense as is. In *my* head, instead of
your <listOfLayouts> element, I envision a <listOfDiagrams>
element, which would contain 0 or more <diagram> elements,
with each <diagram> element containing a <layout> element
and a <render> element. On the other hand, I could also
imagine sticking <render> inside <layout> (although I don't
think that makes sense). Can you say a few words about this?

John


-----Original Message-----
From: Ralph Gauges [mailto:ralph.gauges@eml-r.villa-bosch.de]
Sent: Thu 9/11/2003 4:52 AM
To: Wagner,John
Cc: Herbert Sauro; Herbert M. Sauro; Ralph Gauges; sbml-discuss@caltech.edu
Subject: Re: [sbml-discuss] DWG: Revised Proposal



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

Actually we have not given much thought to the render part yet since we
wanted to get the layout part done first.
We just had a little discussion about it so and what came up was
something very much along the lines of the layout part.

We would take the render information completely out of the layout part
and have a separate <render> part.
Therein we would define a listOfLinetypes for the different line types
we are going to use. Likewise we would have a listOfCurves,
listOfShapes, listOfTextlabels, listOfBitmaps and renderGroups.
Actually the listOfTextlabels might not be necesary since it could be
defined as a kind of shape and put into the listOfShapes.
The ListOfRenderGroups would contain a list of groups that again
contain a
list of references to either curves, shapes or bitmaps and their
relative positions within the group.
The glyphs in the layout part could then reference one of the render
groups.
So the structure would essentialy be something like that

<listOfLayouts>
<layout ...>
...
<speciesGlyph ... rendering="greenRec" .../>
...
</layout ...>
.....
</listOfLayouts>

<render>
<listOfLinetypes>
<lineType id="someLineType" stroke="solid" color="0,0,0,255"
thickness="1" />
....
</listOfLinetypes>
<listOfCurves>
....
</listOfCurves>
<listShapes>
<shape id="greenRec" xsi:type="sr:rectangle" color="0,255,0,255"
linetype="someLineType"/>
....
</listOfShapes>
<listOfBitmaps>
....
</listOfBitmaps>
<renderGroups>
....
</renderGroups>
</render>


I hope this is was not too confusing, but if everyone else thinks that
we have the layout part pretty much covered, we could go ahead and
write this up in a little more detail so that we can discuss about it.

Ralph

P.S.: Concerning the new bounding box for layouts in the layout
proposal, everybody is free to ignore it if their canvas does not have
a limited size. It is not a limit, but rather a hint as to how large
your view needs to be in order to show the whole diagram.



On Donnerstag, September 11, 2003, at 01:00 Uhr, Wagner,John wrote:

> Looking really good, Ralph. One question...
>
> Your document mentions separating layout and render info
> (which I very much like). Obviously, we've not gotten to the
> rendering part, at least not yet. But, what is your vision of
> how rendering would fit into your scheme? One of the
> reasons I ask is, depending on where it fits in, the naming
> might not quite make sense as is. In *my* head, instead of
> your <listOfLayouts> element, I envision a <listOfDiagrams>
> element, which would contain 0 or more <diagram> elements,
> with each <diagram> element containing a <layout> element
> and a <render> element. On the other hand, I could also
> imagine sticking <render> inside <layout> (although I don't
> think that makes sense). Can you say a few words about this?
>
> John
>
>
>

Since we feel that the layout part of the proposal contains more or
less everything that would be needed and nobody told us different, we
sat down and tried to write up a first draft of the render part. It is
basically a more detailed description of what I wrote in my last mail.
Although we made some slight changes in some places.
As mentioned before, the general schema is pretty much the same as for
the layout and we put pretty much emphasis on allowing people to reuse
objects. That is to say, you define a color and can use it in several
places, or you define some shape and use it over and over again in
different sizes.
We hope that people again give us feedback and tell us what they like
or what they dislike. And it is especially what people don't like that
we want to hear.

Ralph

The document can also be found at the usual place
(http://projects.villa-bosch.de/bcb/sbml/)

I was looking at the rendering document and noticed that most of it is in schema notation, probably I'm the only one but I find it difficult to read schema (it's like trying to read a C program that's written in assembler), would it be possible to put more real examples?

Herbert

-----Original Message-----
From: Ralph Gauges [mailto:ralph.gauges@eml-r.villa-bosch.de]
Sent: Thu 9/18/2003 8:11 AM
To: Wagner,John
Cc: Herbert Sauro; Herbert M. Sauro; sbml-discuss@caltech.edu
Subject: Re: [sbml-discuss] DWG: Revised Proposal



Since we feel that the layout part of the proposal contains more or
less everything that would be needed and nobody told us different, we
sat down and tried to write up a first draft of the render part. It is
basically a more detailed description of what I wrote in my last mail.
Although we made some slight changes in some places.
As mentioned before, the general schema is pretty much the same as for
the layout and we put pretty much emphasis on allowing people to reuse
objects. That is to say, you define a color and can use it in several
places, or you define some shape and use it over and over again in
different sizes.
We hope that people again give us feedback and tell us what they like
or what they dislike. And it is especially what people don't like that
we want to hear.

Ralph

The document can also be found at the usual place
(http://projects.villa-bosch.de/bcb/sbml/)

> The layout information is simply that, positional information for the
> varous parts of the diagram? The only information that is given are
> positions of the nodes and the coordinates of the edges?
>

Yes that is correct. The only exception being the
speciesReferenceGlyphs that can specify a curve instead of just a
bounding box.


> Is there any information on objects other than modeling specific
> objects, or is this information reserved for the rendering info (see
> Jonathon's proposal for example).

First of all, the reference to objects in the model is optional for all
Glyph objects, so you can have a CompartmentGlyph in the layout that
does not reference a Compartment in the Model.
For all other objects that have absolutely nothing to do with reaction
networks, we have the listOfAdditionalGraphicalObjects. So if you would
like to include a picture of your red ferrari in the layout, you add
some bounding box to this list and reference a bitmap of the car in the
render parts listOfShapes.

>
> In the proposal you mention the bounding box but don't give an
> example. I can't easily read xml-schema, so I need to ask is the
> bounding box optional? I also notice you have a role attribute, is
> this optional?
>

The bounding box that is mentioned is a set of attributes on the glyph
objects. If you take for example the SpeciesGlyph it has the attributes
x,y,z and w,h,d where z and d are optional and default to 0.0. The
x,y,z attributes are used to set the position of the bounding box and
the w,h,d are the width, height and depth respectively. The x,y,w and h
attributes are not optional, so no, the bounding box is not optional.
The SpeciesReferenceGlyph is somewhat different since it can either
have a bounding box object which again has the above mentioned
attributes or it can have a curve that specifies the arrow that is used
to represent the relation. Actually one of the two should be given, so
there might be a mistake in the schema specification because there it
would be optional.
The role attribute is indeed optional and it can be used to specify the
role of the SpeciesReference in the reaction without having to figure
it out from the kinetics. So if your program draws inhibitors
differently from activators you could specify wether it is one or the
other. If you use the render part as well, this would be redundant
information since you would probably specify the complete render
information there anyway.


> The pseudo node coordinates I presume can coincide? I ask this because
> some of us don't use a straight line segment in the center of the
> reaction arc.
>

Yes the two points of the reaction can coincide. Actually you can
either see those two points as two pseudo nodes or as a bounding box.
In the second case, you could specify some renderGroup (see render
part) to be drawn inside this bounding box. Maybe this is a little
ambiguous and should be changed.

> Without rendering info, is there any recommandation for font sizes
> since you have width and height infor for node sizes, if the font size
> isn't chosen appropriately then the font will over flow the box. I
> think I would like to see something that indicates whether the node
> bounding box should be elastic or fixed, if elastic then the box will
> resize according to the font used. This is what I do in jdesigner and
> it avoids any font sizing issues.

This assumes that everybody will be drawing the nodes as text labels
which might not be the case. Without render information it is up to the
program what is drawn inside the bounding box.
I have not given any thought to elastic bounding boxes yet. Don't they
defy the purpose of a bounding box? If I have some layout, so I want
the program to be able to enlarge bounding boxes even though this might
end up in a messy layout? If a text label would not fit into a given
bounding box, would it not make more sense to have the layout
recalculated?
What do other people think about his?


> On first glance, I can't see anything which records the background
> colour? Do you have one?
>
Short answer: not yet.
Longer answer: Since we did not specify concrete examples for shapes,
we did not bother with their details yet. All the document states so
far is that there will de an abstract class shape and that all shapes
that will eventually be defined are subclasses of Shape. We are not
sure yet if it would make sense to have an attribute for background
color in Shape directly rather than in the subclasses (where needed).
E.g. you might not need a background color for text label shapes or
bitmaps. Actually depending on how we handle this, a background color
may not be needed at all. You could for example just draw some text on
a filled rectangle that has the color you want as the background.


> I was looking at the rendering document and noticed that most of it is
> in schema notation, probably I'm the only one but I find it difficult
> to read schema (it's like trying to read a C program that's written in
> assembler), would it be possible to put more real examples?
>

I don't think you would be the only one having difficulties reading the
schema notation and as you can see from the mistakes that I made
writing it, I am not as comfortable with it as I would wish. Actually
we had hoped that the text would make the points clear we were trying
to make without having to rely on the schema. Obviously this is not the
case and I apologize for that. As this is just a first draft and
doesn't have all the features that are needed, it is somehow difficult
to give examples. I tried to make up a short example towards the end to
demonstrate how layout and render information would play together. For
this I already made up some Shapes like text labels and circle, but as
I just said, I made this just up for this example, we haven't defined
any concrete shapes yet. We had hoped to get some feedback as to what
kind of shapes people would need first. So could you tell us what kind
of basic shapes you would like to have and the properties they need. As
stated in the document, we are probably going to borrow some of the
notation from SVG, we only need to know what is needed first.



I hope I could clarify some of the issues raised.
Thanks a lot for the feedback and we hope to hear more along this line

Ralph