sbml-render Mailing List for Systems Biology Markup Language (SBML)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Please note the current SBML Editors will continue to work on this 
publication and it will proceed as planned.

SBML Editors

Sorry I was perhaps not completely clear.

Nicolas Le Novere has withdrawn from the paper and has handed over all 
notes/comments etc to the remaining SBML Editors.

There will be a slight hiatus in the timing, but we are close to having 
a manuscript for submission, and we will proceed with this.

Thank you to everyone who has commented so far and I hope this 
completely clarifies the situation.

Sarah
Coordinator of SBML Editors

On 18/09/2018 09:04, Sarah Keating wrote:
> Please note the current SBML Editors will continue to work on this
> publication and it will proceed as planned.
> 
> SBML Editors
> 

Dear Colleagues,

We are in the process of submitting a manuscript describing SBML Level 3 for publication in Molecular Systems Biology as a perspective (current version attached). The manuscript has been written by past and current SBML editors and both its content and structure discussed with MSB editors.

Although the structure and the main messages of the paper have been settled, we would welcome any suggestion you would have in relation with the manuscript.

Best regards

The SBML editors.

Dear SBML community,

We are pleased to announce the availability of the final Version 1
specification for the Render package in SBML Level 3. You can find the
document at its resolvable URI:

http://identifiers.org/combine.specifications/sbml.level-3.version-1.render.version-1.release-1

This specification has been approved by the editors who have confirmed
there are two working implementations.

The Render ('render') specification activity page is:

http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/render

Please report any errors, issues or questions to the Package Working
Group for 'render' (sbm...@li...).

Thanks again to all the people who have helped to shape this final
version of the specification.

Cheers
Frank T. Bergmann
- on behalf of the authors of the render specification

Dear SBML Editors

We submit the release candidate of the render specification for final 
approval.

https://sourceforge.net/p/sbml/code/HEAD/tree/trunk/specifications/sbml-level-3/version-1/render/sbml-render-version-1-rc1.pdf

There are three separate software implementations of the SBML L3 Render 
package:

1. COPASI available from http://copasi.org/
2. SBML Layout Web Application: http://sysbioapps.dyndns.org/Layout
3. SBW http://sbw.sourceforge.net/.

These will all read and write render (and obviously layout) as both the 
L2 annotation version and as L3 package information and thus can 
demonstrate exchange and round tripping of this information.

We recognize that there are improvements/changes that could be made but 
given the historical nature of this package doing these changes would 
mean there were no implementations that supported them. So we are asking 
that the editors accept the current specification as-is and allow any 
further development to be done as a version 2.

Thanks

Authors of Render

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
sbml-render mailing list
sbm...@li...
https://lists.sourceforge.net/lists/listinfo/sbml-render

Wooohoooo!  Well done!

On Fri, 22 Sep 2017 13:02:19 +0100, Sarah Keating wrote:
> Dear Render people
> 
> https://sourceforge.net/p/sbml/code/HEAD/tree/trunk/specifications/sbml-level-3/version-1/render/sbml-render-version-1-rc1.pdf
> 
> We have addressed any comments made on the spec and are ready to 
> submit the spec to the SBML Editors for final approval.
> 
> We will include the information below regarding implementations and 
> intend to submit this to the editors next week; unless anyone raises 
> objections.
> 
> Sarah + Frank
> 
> Message to Editors
> ===============
> 
> There are three separate software implementations of the SBML L3 
> Render package:
> 
> 1. COPASI available from http://copasi.org/
> 2. SBML Layout Web Application: http://sysbioapps.dyndns.org/Layout
> 3. SBW http://sbw.sourceforge.net/.
> 
> These will all read and write render (and obviously layout) as both 
> the L2 annotation version and as L3 package information and thus can 
> demonstrate exchange and round tripping of this information.
> 
> We recognize that there are improvements/changes that could be made 
> but given the historical nature of this package doing these changes 
> would mean there were no implementations that supported them. So we 
> are asking that the editors accept the current specification as-is 
> and allow any further development to be done as a version 2.
> 
> Thanks
> 
> Authors of Render
> 
> =========
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> sbml-render mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-render

Dear Render people

https://sourceforge.net/p/sbml/code/HEAD/tree/trunk/specifications/sbml-level-3/version-1/render/sbml-render-version-1-rc1.pdf

We have addressed any comments made on the spec and are ready to submit 
the spec to the SBML Editors for final approval.

We will include the information below regarding implementations and 
intend to submit this to the editors next week; unless anyone raises 
objections.

Sarah + Frank

Message to Editors
===============

There are three separate software implementations of the SBML L3 Render 
package:

1. COPASI available from http://copasi.org/
2. SBML Layout Web Application: http://sysbioapps.dyndns.org/Layout
3. SBW http://sbw.sourceforge.net/.

These will all read and write render (and obviously layout) as both the 
L2 annotation version and as L3 package information and thus can 
demonstrate exchange and round tripping of this information.

We recognize that there are improvements/changes that could be made but 
given the historical nature of this package doing these changes would 
mean there were no implementations that supported them. So we are asking 
that the editors accept the current specification as-is and allow any 
further development to be done as a version 2.

Thanks

Authors of Render

=========

Good work! Thanks!

MH

On Sat, 24 Jun 2017 21:35:59 +0100, Sarah Keating wrote:
> Hi People
> 
> So I finally looked at Lucian's comments and fixed typos, added 
> further text to some things etc.
> 
> I created a spreadsheet of the comments. Green means it is done. The 
> other things are outstanding and require input from other people.
> 
> https://docs.google.com/spreadsheets/d/1OSDwOrK0YHE-RlXzHh1n5YzIrUDT-ZdYITWwgVeSwyk/edit?usp=sharing
> 
> The result so far is here:
> 
> https://sourceforge.net/p/sbml/code/24316/tree//trunk/specifications/sbml-level-3/version-1/render/render-version-1-draft-2.pdf
> 
> We definitely do need more examples of xml and the resulting 'drawing' :-)
> 
> Sarah
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> sbml-render mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-render

Hi People

So I finally looked at Lucian's comments and fixed typos, added further 
text to some things etc.

I created a spreadsheet of the comments. Green means it is done. The 
other things are outstanding and require input from other people.

https://docs.google.com/spreadsheets/d/1OSDwOrK0YHE-RlXzHh1n5YzIrUDT-ZdYITWwgVeSwyk/edit?usp=sharing

The result so far is here:

https://sourceforge.net/p/sbml/code/24316/tree//trunk/specifications/sbml-level-3/version-1/render/render-version-1-draft-2.pdf

We definitely do need more examples of xml and the resulting 'drawing' :-)

Sarah

You are welcome, and  a merry xmas to you and yours

cheers
Frank

On Wed, Dec 21, 2016 at 9:34 PM, Andreas Dräger
<dr...@in...> wrote:
>> Am 21.12.2016 um 21:29 schrieb Frank T. Bergmann <fbe...@ca...>:
>>
>> No ... to link the styles you have the following options:
>>
>> - add the graphicalObjects id to the idList of a local style
>> - add an objectRole attribute to the graphical object and use the
>> roleList on a style to apply it to it (if no style with the objects id
>> is applied)
>> - add an type of an object to the typeList of a style (of no style
>> could be applied via idList / roleList)
>>
>> cheers
>> Frank
>
>
> Thanks, that's how I understood it.
>
> Ok, so, I can't say GraphicalObject links to Style with id, but to a Style whose roleList contains the objectRole of the Graphical Object.
>
> With best regards and merry X-mas!
>
> Dr. Andreas Draeger
> Principal Investigator
> ---
> University of Tuebingen
> Center for Bioinformatics Tuebingen (ZBIT)
> Applied Bioinformatics Group
> Sand 14 · Office #A313 · 72076 Tübingen · Germany
> Phone: +49-7071-29-78982 · Fax: +49-7071-29-5152
> Web: http://draeger-lab.org · Twitter: @dr_drae
> YouTube: https://www.youtube.com/channel/UCp7fWtXGFOIjV35u7ONiVbg
>
>
>
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/intel
> _______________________________________________
> sbml-render mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-render

> Am 21.12.2016 um 21:29 schrieb Frank T. Bergmann <fbe...@ca...>:
> 
> No ... to link the styles you have the following options:
> 
> - add the graphicalObjects id to the idList of a local style
> - add an objectRole attribute to the graphical object and use the
> roleList on a style to apply it to it (if no style with the objects id
> is applied)
> - add an type of an object to the typeList of a style (of no style
> could be applied via idList / roleList)
> 
> cheers
> Frank

Thanks, that's how I understood it.

Ok, so, I can't say GraphicalObject links to Style with id, but to a Style whose roleList contains the objectRole of the Graphical Object.

With best regards and merry X-mas!

Dr. Andreas Draeger
Principal Investigator
---
University of Tuebingen
Center for Bioinformatics Tuebingen (ZBIT)
Applied Bioinformatics Group
Sand 14 · Office #A313 · 72076 Tübingen · Germany
Phone: +49-7071-29-78982 · Fax: +49-7071-29-5152
Web: http://draeger-lab.org · Twitter: @dr_drae
YouTube: https://www.youtube.com/channel/UCp7fWtXGFOIjV35u7ONiVbg

No ... to link the styles you have the following options:

- add the graphicalObjects id to the idList of a local style
- add an objectRole attribute to the graphical object and use the
roleList on a style to apply it to it (if no style with the objects id
is applied)
- add an type of an object to the typeList of a style (of no style
could be applied via idList / roleList)

cheers
Frank

On Wed, Dec 21, 2016 at 9:19 PM, Andreas Dräger
<dr...@in...> wrote:
>> Am 21.12.2016 um 21:14 schrieb Frank T. Bergmann <fbe...@ca...>:
>>
>> Hello Andreas,
>>
>> there is no inconsistency here. If a style is bound to an element via
>> id, that style will always be applied to that object. The second level
>> of binding styles is the role attribute, where you can apply styles to
>> all elements that have a certain objectRole attribute set on them.
>> Consider the case where you would like to highlight a certain portion
>> of your layout (that has no styles bound to them via ids) by a certain
>> style (say all red / thickish lines). Another use case where I often
>> use this is to apply consistent arrow heads to reaction arcs. If no
>> style is defined by id or objectRole, then the last way to assign
>> styles is by the type of object (render all compartments a certain
>> way, or all species ... ).
>>
>> Using objectRoles or types makes it possible to define style sheets
>> ahead of time and then simply apply them to the same layout.
>>
>> I hope this makes it clearer,
>>
>> all the best
>> Frank
>>
>> On Wed, Dec 21, 2016 at 5:32 PM, Andreas Dräger
>> <dr...@in...> wrote:
>>> Dear all,
>>>
>>> If I want to draw a species glyph in a certain color, one option to do so is this:
>>>
>>> …
>>> <render:listOfColorDefinitions>
>>> <render:colorDefinition render:id="color_1" render:value="#00FF33FF" />
>>> </render:listOfColorDefinitions>
>>> <render:listOfStyles>
>>> <render:listOfStyles>
>>>   <render:style id="fill_1" render:roleList="style_fill_1">
>>>     <render:g render:fill="color_1" />
>>>    </render:style>
>>> </render:listOfStyles>
>>> </render:listOfStyles>
>>> …
>>>
>>> And then my species glyph would be
>>>
>>> <layout:speciesGlyph layout:id="SpeciesGlyph_sa7126" layout:species="s6285" render:objectRole="style_fill_1">
>>>
>>> I'd like to know what the rationale is behind the definition of role lists on styles? Why is it not sufficient to simply link to the id of a style instead?
>>>
>>> The role list can be a blank-separated enumeration of many roles, making the interpretation of these files a bit cumbersome. Just now, I don't see the advantage of doing so.
>>>
>>> Interestingly, there is another alternative, in which I would have an idList in the style that would enumerate all the ids of graphical objects with that style. Why are there two ways of doing it? Can't this open the door for inconsistencies? In fact, the idList is even more difficult to handle because when deleting a graphical object, all idLists must be queried for invalid references to that graphical object. For very large models, these idLists also tend to become very long. A bit explanation why this was designed as such and where the advantages/use cases are would be appreciated.
>>>
>>> With best regards and thanks
>>>
>>> Dr. Andreas Draeger
>
>
> Thanks, Frank!
>
> So, how would I link a style to a GraphicalObject using the style's id?
>
> With best regards
>
> Dr. Andreas Draeger
> Principal Investigator
> ---
> University of Tuebingen
> Center for Bioinformatics Tuebingen (ZBIT)
> Applied Bioinformatics Group
> Sand 14 · Office #A313 · 72076 Tübingen · Germany
> Phone: +49-7071-29-78982 · Fax: +49-7071-29-5152
> Web: http://draeger-lab.org · Twitter: @dr_drae
> YouTube: https://www.youtube.com/channel/UCp7fWtXGFOIjV35u7ONiVbg
>
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/intel
> _______________________________________________
> sbml-render mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-render

> Am 21.12.2016 um 21:14 schrieb Frank T. Bergmann <fbe...@ca...>:
> 
> Hello Andreas,
> 
> there is no inconsistency here. If a style is bound to an element via
> id, that style will always be applied to that object. The second level
> of binding styles is the role attribute, where you can apply styles to
> all elements that have a certain objectRole attribute set on them.
> Consider the case where you would like to highlight a certain portion
> of your layout (that has no styles bound to them via ids) by a certain
> style (say all red / thickish lines). Another use case where I often
> use this is to apply consistent arrow heads to reaction arcs. If no
> style is defined by id or objectRole, then the last way to assign
> styles is by the type of object (render all compartments a certain
> way, or all species ... ).
> 
> Using objectRoles or types makes it possible to define style sheets
> ahead of time and then simply apply them to the same layout.
> 
> I hope this makes it clearer,
> 
> all the best
> Frank
> 
> On Wed, Dec 21, 2016 at 5:32 PM, Andreas Dräger
> <dr...@in...> wrote:
>> Dear all,
>> 
>> If I want to draw a species glyph in a certain color, one option to do so is this:
>> 
>> …
>> <render:listOfColorDefinitions>
>> <render:colorDefinition render:id="color_1" render:value="#00FF33FF" />
>> </render:listOfColorDefinitions>
>> <render:listOfStyles>
>> <render:listOfStyles>
>>   <render:style id="fill_1" render:roleList="style_fill_1">
>>     <render:g render:fill="color_1" />
>>    </render:style>
>> </render:listOfStyles>
>> </render:listOfStyles>
>> …
>> 
>> And then my species glyph would be
>> 
>> <layout:speciesGlyph layout:id="SpeciesGlyph_sa7126" layout:species="s6285" render:objectRole="style_fill_1">
>> 
>> I'd like to know what the rationale is behind the definition of role lists on styles? Why is it not sufficient to simply link to the id of a style instead?
>> 
>> The role list can be a blank-separated enumeration of many roles, making the interpretation of these files a bit cumbersome. Just now, I don't see the advantage of doing so.
>> 
>> Interestingly, there is another alternative, in which I would have an idList in the style that would enumerate all the ids of graphical objects with that style. Why are there two ways of doing it? Can't this open the door for inconsistencies? In fact, the idList is even more difficult to handle because when deleting a graphical object, all idLists must be queried for invalid references to that graphical object. For very large models, these idLists also tend to become very long. A bit explanation why this was designed as such and where the advantages/use cases are would be appreciated.
>> 
>> With best regards and thanks
>> 
>> Dr. Andreas Draeger

Thanks, Frank!

So, how would I link a style to a GraphicalObject using the style's id?

With best regards

Dr. Andreas Draeger
Principal Investigator
---
University of Tuebingen
Center for Bioinformatics Tuebingen (ZBIT)
Applied Bioinformatics Group
Sand 14 · Office #A313 · 72076 Tübingen · Germany
Phone: +49-7071-29-78982 · Fax: +49-7071-29-5152
Web: http://draeger-lab.org · Twitter: @dr_drae
YouTube: https://www.youtube.com/channel/UCp7fWtXGFOIjV35u7ONiVbg

Hello Andreas,

there is no inconsistency here. If a style is bound to an element via
id, that style will always be applied to that object. The second level
of binding styles is the role attribute, where you can apply styles to
all elements that have a certain objectRole attribute set on them.
Consider the case where you would like to highlight a certain portion
of your layout (that has no styles bound to them via ids) by a certain
style (say all red / thickish lines). Another use case where I often
use this is to apply consistent arrow heads to reaction arcs. If no
style is defined by id or objectRole, then the last way to assign
styles is by the type of object (render all compartments a certain
way, or all species ... ).

Using objectRoles or types makes it possible to define style sheets
ahead of time and then simply apply them to the same layout.

I hope this makes it clearer,

all the best
Frank

On Wed, Dec 21, 2016 at 5:32 PM, Andreas Dräger
<dr...@in...> wrote:
> Dear all,
>
> If I want to draw a species glyph in a certain color, one option to do so is this:
>
> …
> <render:listOfColorDefinitions>
>   <render:colorDefinition render:id="color_1" render:value="#00FF33FF" />
> </render:listOfColorDefinitions>
> <render:listOfStyles>
>   <render:listOfStyles>
>     <render:style id="fill_1" render:roleList="style_fill_1">
>       <render:g render:fill="color_1" />
>      </render:style>
>   </render:listOfStyles>
> </render:listOfStyles>
> …
>
> And then my species glyph would be
>
> <layout:speciesGlyph layout:id="SpeciesGlyph_sa7126" layout:species="s6285" render:objectRole="style_fill_1">
>
> I'd like to know what the rationale is behind the definition of role lists on styles? Why is it not sufficient to simply link to the id of a style instead?
>
> The role list can be a blank-separated enumeration of many roles, making the interpretation of these files a bit cumbersome. Just now, I don't see the advantage of doing so.
>
> Interestingly, there is another alternative, in which I would have an idList in the style that would enumerate all the ids of graphical objects with that style. Why are there two ways of doing it? Can't this open the door for inconsistencies? In fact, the idList is even more difficult to handle because when deleting a graphical object, all idLists must be queried for invalid references to that graphical object. For very large models, these idLists also tend to become very long. A bit explanation why this was designed as such and where the advantages/use cases are would be appreciated.
>
> With best regards and thanks
>
> Dr. Andreas Draeger
> Principal Investigator
> ---
> University of Tuebingen
> Center for Bioinformatics Tuebingen (ZBIT)
> Applied Bioinformatics Group
> Sand 14 · Office #A313 · 72076 Tübingen · Germany
> Phone: +49-7071-29-78982 · Fax: +49-7071-29-5152
> Web: http://draeger-lab.org · Twitter: @dr_drae
> YouTube: https://www.youtube.com/channel/UCp7fWtXGFOIjV35u7ONiVbg
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/intel
> _______________________________________________
> sbml-render mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-render

Dear all,

If I want to draw a species glyph in a certain color, one option to do so is this:

…
<render:listOfColorDefinitions>
  <render:colorDefinition render:id="color_1" render:value="#00FF33FF" />
</render:listOfColorDefinitions>
<render:listOfStyles>
  <render:listOfStyles>
    <render:style id="fill_1" render:roleList="style_fill_1">
      <render:g render:fill="color_1" />
     </render:style>
  </render:listOfStyles>
</render:listOfStyles>
…

And then my species glyph would be 

<layout:speciesGlyph layout:id="SpeciesGlyph_sa7126" layout:species="s6285" render:objectRole="style_fill_1">

I'd like to know what the rationale is behind the definition of role lists on styles? Why is it not sufficient to simply link to the id of a style instead?

The role list can be a blank-separated enumeration of many roles, making the interpretation of these files a bit cumbersome. Just now, I don't see the advantage of doing so.

Interestingly, there is another alternative, in which I would have an idList in the style that would enumerate all the ids of graphical objects with that style. Why are there two ways of doing it? Can't this open the door for inconsistencies? In fact, the idList is even more difficult to handle because when deleting a graphical object, all idLists must be queried for invalid references to that graphical object. For very large models, these idLists also tend to become very long. A bit explanation why this was designed as such and where the advantages/use cases are would be appreciated.

With best regards and thanks

Dr. Andreas Draeger
Principal Investigator
---
University of Tuebingen
Center for Bioinformatics Tuebingen (ZBIT)
Applied Bioinformatics Group
Sand 14 · Office #A313 · 72076 Tübingen · Germany
Phone: +49-7071-29-78982 · Fax: +49-7071-29-5152
Web: http://draeger-lab.org · Twitter: @dr_drae
YouTube: https://www.youtube.com/channel/UCp7fWtXGFOIjV35u7ONiVbg

1) I was hoping that the first version of the Render package is done :)
2) the feedback we received last time was a request for primarily
typos and formatting changes.
3) The specification was written and re-written twice now. to adapt
for the format changes required by the editors. The current draft spec
was brought out primarily by Sarah and me, with large parts of the
text still stemming from the original version.
4) there are two complete implementations with COPASI and SBW  ... as
well as software support in and outside of libSBML and JSBML.

Cheers
Frank

On Tue, Dec 6, 2016 at 5:16 PM, Andreas Dräger
<and...@un...> wrote:
> Dear all,
>
> I'd like to ask a few questions about the render package:
> 1) What is the current state of the render package?
> 2) How much still remains to do before it can be finalized?
> 3) Who is currently working as an active developer on this package?
> 4) What are known implementations and how complete are they?
>
> With best regards
>
> Dr. Andreas Draeger
> Principal Investigator
> ---
> University of Tuebingen
> Center for Bioinformatics Tuebingen (ZBIT)
> Applied Bioinformatics Group
> Sand 14 · Office #A313 · 72076 Tübingen · Germany
> Phone: +49-7071-29-78982 · Fax: +49-7071-29-5152
> Web: http://draeger-lab.org · Twitter: @dr_drae
> YouTube: https://www.youtube.com/channel/UCp7fWtXGFOIjV35u7ONiVbg
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/xeonphi
> _______________________________________________
> sbml-render mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-render

Dear all,

I'd like to ask a few questions about the render package:
1) What is the current state of the render package? 
2) How much still remains to do before it can be finalized?
3) Who is currently working as an active developer on this package?
4) What are known implementations and how complete are they?

With best regards

Dr. Andreas Draeger
Principal Investigator
---
University of Tuebingen
Center for Bioinformatics Tuebingen (ZBIT)
Applied Bioinformatics Group
Sand 14 · Office #A313 · 72076 Tübingen · Germany
Phone: +49-7071-29-78982 · Fax: +49-7071-29-5152
Web: http://draeger-lab.org · Twitter: @dr_drae
YouTube: https://www.youtube.com/channel/UCp7fWtXGFOIjV35u7ONiVbg

Dear PWG,

Thanks for this great effort and drafting this large specification document. This is a significant improvement compared to the previous proposal.

I am here commenting on some notes by Lucian.

> Am 12.05.2015 um 21:18 schrieb Lucian Smith <luc...@gm...>:
> 
> This looks great!  Here's my comments, such as they are.  There ended up being quite a lot of them, but it's a huge spec.  Fortunately, I don't think any of them are very substantial.
> [...]
> p. 18: "Style is an abstract class..." As far as I can tell, Style is not an abstract class, but a normal class.  Nothing seems to derive from it, even.

According to Fig. 5, there are LocalStyle and GlobalStyle both derived from the abstract class Style.

> [...]
> p. 22:  In general, it's odd to me that all of the attributes of a LinearGradient and a RadialGradient are optional.  Aren't at least all the x and y values required?  Are there situations where

????

> [...]
> p. 71:  "One of these initiatives, the sboTerms, is about to be included into SBML Level 2 Version 2."  Wow, this spec has been around forever, hasn't it?  If you want to use sboTerms to define roles, you should probably decide now if you want to do so.  If not, just drop this section, or say why this was never implemented.

I agree and highly suggest to move to SBO terms. At least for the roles that are defined in the Layout package, all corresponding terms have been defined in SBO already. At least, there should be a table that defines the relationship between roles and corresponding SBO terms.

> I ran out of steam and didn't read the validation rules, but yay them being there.

Is there a schedule when an updated version of this spec will be made available that addresses Lucian's coments somehow?

Cheers
Dr. Andreas Dräger
Center for Bioinformatics Tuebingen (ZBIT), Dept. Cognitive Systems,
University of Tuebingen, Sand 1, Office #A313, 72076 Tübingen, Germany
Phone: +49-7071-29-78982, Fax: +49-7071-29-5091, twitter: @dr_drae

This looks great!  Here's my comments, such as they are.  There ended up
being quite a lot of them, but it's a huge spec.  Fortunately, I don't
think any of them are very substantial.

p. 5:  I don't understand the 'red' parts.  I read it as they're red
because they're underdefined in the UML but fully defined in the text, but
I think what it actually means is that they're fully defined in a *later*
figure, cf 'ListOfColorDefinitions' in figure 2 (red) vs. figure 6 (blue).
Is this correct?  If this text could be more clear, that'd be great.

p. 8:  FillRule:  It would be nice if at least a brief overview of what
'nonzero' and 'evenodd' mean was included, instead of only having a
reference to SVG.

p. 9:  Figure 1 would be slightly more clear with dotted lines showing
where the defined parts end and the extrapolated bits begin, ideally
labelled above.

p. 10 line 28 is a comma splice:  "...that complements it, this way..."
 Making it a period or maybe a semicolon would work.

p. 10 section 3.3.1  I didn't understand this section at all.  What has to
be unique, and why?  Are these SIds that have to sort of be unique, or
SIdRefs?

p. 12:  DefaultValues:  The default values are both optional, and all their
attributes are optional, so what happens if a rendering application
encounters a situation for which there is no default?  Does it give up?
Should it pick whatever it wants?  Also, I can make an educated guess that
global defaults can be overridden by local default, which can be overridden
by specific declarations on particular items.  But I don't see this
actually written up anywhere.

p. 14:  versionMajor and versionMinor:  Are these holdovers from when
Render was an l2 package?  Do they still serve some purpose?  If they're
functionally equivalent to the level of the package itself, I don't think
we need them any more, unless you want them for some sort of backwards
compatibility issue?  Either way, it's hard to tell from the spec what the
purpose of these attributes is, nor what their values should be.

p. 14: "can encode that version information there is no relation to the
SBML attributes level and version."  <-- not grammatical, and I can't tell
what is being said.

p. 15:  versionMajor and versionMinor again.  Do these have to match the
ones on p. 14?  What do they mean?  What version is this specification?
What does it mean that "All minor versions within a major version have to
be compatible."?  What does 'compatible' mean in this context?  Also, it
sounds like minor versions have to be *forward* compatible with other minor
versions which sounds difficult.

p. 15: referenceRenderInformation.  It says, "A program reading and
interpreting the render information can use this information to access
another render information object, should the current object contain
unsuitable information."  I don't know what 'unsuitable' means.  Missing
information?  Incorrect information?  Correct information that cannot be
used by the current interpreter?

p. 16: referenceRenderInformation: I don't know what 'already been defined'
means.  Is this a holdover from when order was important?  If so, it will
need to be changed, since order is supposed to be irrelevant in L3 packages
(which should be simple enough; just say 'no loops'.)

p. 16: backgroundColor:  Are there a list of allowed strings for this, or
can I put in whatever I want?  Is it legal to have a backgroundColor of
'dusty rose', 'off-white' 'puce', or 'grasshopper'?  Is there any
relationship between 'backgroundColor' and ColorDefinitions?  If so, what
is it?  If not, why isn't there?  EDIT:  OK, now that I've read the rest of
the spec, my guess is that this is supposed to be one of the 'hex value or
ColorDefinition reference' elements.  It would be nice if this was defined
as a Type, so you only had to describe it once, and you could answer my
other questions re: formatting.

p. a bunch:  Many classes claim to derive from the 'ListOf' class, but
there is no such class defined in SBML core.  There's a ListOf class
defined in libsbml, but that's not in the spec.

p. 16: 'classand' <- missing space.

p. 18: "Style is an abstract class..." As far as I can tell, Style is not
an abstract class, but a normal class.  Nothing seems to derive from it,
even.

p. 18:  "Note this relationship is only valid if there is no render
information object that is more specific."  It would be nice if there was a
single global list somewhere of what was specifically meant by this.  There
are types, roles, IDs, local and global things that might have ids and
roles and styles too (maybe?)... A single place that defines what the order
is would be great.

p. 19:  There's a weird symbol in the example XML that looks like a bracket
fell over in the middle of "SPECIESGLYPH SPECIESREFERENCEGLYPH" (where the
space should be).

Figure 6:  The ColorDefinition UML implies that the attributes are
required, but the text says otherwise ("In addition the ColorDefinition
object has the optional attributes id and value.")

p. 20:  The 'value' attribute claims to be a '6 to 8' digit number, but if
I'm reading it correctly, 7 digits would actually be illegal.  Probably
should be '6 or 8'.

p. 20:  The 'value' attribute values are confusing as to how they should or
may be written.  The text gives a value of "0xff" but then the example has
"#200000".  Do you have to use the "#" form?  Could you put in "0xff" (or
"0xFF") as the attribute and have it mean the same thing?  Could you give
the base-10 version?  What are the options; what is legal, and what is not
legal?

p. 20: 'offset':  This claims that the attribute must be defined either as
x1, y1, z1, or as fx, fy, fz.  What about cases where there are only two
displayed dimensions?  Must a '0' be supplied for the 'z' position, or is
it OK to only provide x and y?

p. 20: 'spreadMethod':  This claims to be an attribute of type
'GradientSpreadMethod' in the text, but the UML claims the type is
'spreadMethod'.  'GradientSpreadMethod' should also be used in Figure 1 and
Figure 4.

Figure 7:  The UML defines a 'Stop' class, but it is a 'GradientStop' class
in the text.  And would its element name be 'stop' or 'gradientStop'?

p. 21: 'stop-color':  It seems to me that it might be possible to have a
hexadecimal color value that was also the ID of a ColorDefinition, i.e.
'ff'.  Is this wrong?  It would be helpful to define explicitly what is
meant by 'a hexadecimal color value', here and elsewhere.

p. 21: "adjusted to be either 0% is the given value..." <- 'if', not 'is'.

p. 21  "The offset of any gradient stop has to be greater or equal to the
offset of the preceding gradient stop. If a gradient stop has an offset
that is smaller than the offset of the preceding stop, the offset is
considered to have the same value as the offset of the preceding stop."  It
seems weird to me to simultaneously say that a particular condition is
illegal, and then proceed to say what to do when that illegal condition is
met.  Maybe make this a validation warning instead of a validation error?
Or just don't say what to do if you get an illegal model?

p. 21  "If two gradient stops have the same offset value, the last gradient
stop with this offset value determines the color at this point in the
gradient."  Is this order-dependent?  If so, it should be replaced by a
statement that it's simply illegal to have two gradient stops with the same
offset value.

p. 22: "The attributes x1, y1 and tokenz1 "  and then later "The attributes
x2, y2 and tokenz2":  latex error.

p. 22:  In general, it's odd to me that all of the attributes of a
LinearGradient and a RadialGradient are optional.  Aren't at least all the
x and y values required?  Are there situations where

Figure 8:  I can't tell by eye what bits from the XML correspond to what
bits of the figure.  Where exactly do 000F60 and 000FF6 correspond?  Can
you draw out the gradients, and say why they're going the way they're
going?  Not knowing SVG, I can't tell what's going on here.

p. 23: 'should be positive'  If only 'should', what happens when it's
negative?  If it's an actual error to be negative, change to 'must'.

Figure 9: It would be nice to have labels for this one too, as there is for
Fig 8.  Also, I thought that something that went from one color to another
and then back had to have spreadMethod of 'reflected'?  Am I just wrong, or
is there a 'reflected' somewhere that's not displayed in the example?

p. 23:  "The Transformation class is a common base class for all elements
that can be drawn. Since both the Layout package and the Render package are
currently limited to two dimensions, this class is only used as a base
class for Transformation2D and we leave the complete specification of this
class for a future version of this document."  I don't think this statement
is true--there are a variety of things in the layout spec that have a third
dimension.  Does this mean we need a Transformation3D element, too?  If
not, just say, "Even though we can do 3D things, there hasn't been any call
for a Transformation3D class, so we haven't created one yet." or something.

p. 24:  "A Transformation has a required attribute transform consisting of
an array of type double."  However, the UML claims that the type is
'string'.

p. 24: "This specifies an affine transformation matrix in three dimensions
in which case the array must consist of exactly 12 values."  Didn't you
just say you couldn't do a 3D transformation?  What's going on here?

p. 24-25  It would be nice to confirm that in the illustrated case, the
child object ends up getting transformed twice--once by the transform on
itself, and once for the transform on its group.  Assuming that this is
true.

p. 25:  I'm going to guess that since Render is overlaid on top of Layout,
that if something is not specified, that means that the renderer can do
whatever it likes, just like it could with layout?  So in general, Render
is an optional layer that can parts of information to a layout to add
*some* render information, but need not add *all* render information?  It
would be nice to have this stated explicitly somewhere, perhaps in the
proposed 'what are the defaults' list--it's probably also worth mentioning
that if nothing in Render defines an aspect of the drawing, the tool is to
pick something that makes sense to it.

p. 25: stroke-width:  What are the units of the stroke width?  Pixels?

General:  You have types listed in the same font as classes, which is not
the standard for the SBML core specification.  (FillRule,
GradientSpreadMethod).  This greatly confused me the first time I was
reading, as I assumed those were classes, not types.  Also, all the links
go to the section in general, and not to the particular type listed.

p. 26: 'form the Layout package' -> 'from the Layout package'

p. 27:  listOfElements:  This is an ordered list, which in general we try
to avoid in SBML packages, though perhaps here it can't be avoided?  In
other packages, we get around this by adding an 'index' attribute.  Render
is old enough that perhaps it's OK and we can grandfather this in, but it's
probably worth checking with the editors.

p. 27:  What is this 'xsi' namespace?  It's never defined, and never stated
why we're using it.  Also, it's called 'namespaces' and probably should be
'namespace'.  And... why?  Why do you need it, if it's always the same
value?   It seems to compensate for the fact that the element name is
'element' instead of 'renderPoint'--was that an old decision that can't be
revisited at this point?

p. 28:  It would be nice to see the actual curve produced by this XML,
illustrated by showing the control points, vectors, etc.

p. 30:  "That is the last point" -> "That is, the last point"

Figure 13:  This is great!  This is exactly the sort of figure I would have
liked to see for the other elements.

p. 31: width, height, rx, ry:  Am I correct that even though the type of
these values is the RelAbsVector, that the vector in question should only
be one element long?  Is there a check for that somewhere?  It might be
useful to have two different types, RelAbsValue and RelAbsVector, since
there are (I think) a lot of attributes that can only have one value in
them.

p. 31:  ratio (both):  Must these be positive values?  If not, what do
negative values mean?

p. 31:  "we limit the display of text to normal text, outlined or
filled-outlined text are not supported."  Using a comma here is basically
incorrect--either break off the second bit as a new sentence, or use a
colon.

p. 32:  Can the Image class be given a 'name'?  We usually give a name
attribute to anything with an ID.

p. 32:  "within it’s bounding box" -> its

p. 33:  "not to RenderCurve objects within the group/needis that not a
contradiction"  What?  Was that a note to yourself that accidentally was
uncommented?  I don't know what is going on here.

p. 33: " andvtext-anchor"  need space.

p. 33:  various 'font' attributes:  Are these again sort of local defaults
for their children, but which their children can override with more
specific entries?  If so, this needs to go on the 'defaults' table (that
doesn't yet exist, but which I would like to see).

p. 33: "necessarty" -> necessary

p. 33:  Another class with an 'id' that should probably also be given a
'name'.

p. 34:  enableRotationalMapping attribute:  This is listed as an optional
attribute, but not only is it Boolean, you also (much later) claim that it
has a default value, which is a no-no in L3 packages.  The attribute should
be required.

Figure 15:  Another great figure.

p. 67:  "If the enableRotationalMapping attribute is set to “true”, which
is the default"  The attribute should have no default (see above)

p. 67:  "The first example as depicted in Figure Figure 24"  figure
references in LaTeX no longer need the additional word 'Figure'.  (same for
fig. 25)

p. 67:  "arrow heads coordiante" -> coordinate

p. 69:  "in the normlized vector" -> normalized

p. 67-69:  Capitalize the first word of your three steps ('calculate' ->
'Calculate')

p. 71:  " if there are several styles with the same specificity, the first
one encountered in the file is to be used."  More file-order dependence!
Can we get rid of this, and just say that it's wrong to define the same
thing twice?

p. 71:  Ah, here's the section I wanted on defaults.  It is basically OK,
but I think I would like some more clarity and some examples.  Also, where
I was complaining earlier, maybe add a reference to section C.2.

p. 71:  "One of these initiatives, the sboTerms, is about to be included
into SBML Level 2 Version 2."  Wow, this spec has been around forever,
hasn't it?  If you want to use sboTerms to define roles, you should
probably decide now if you want to do so.  If not, just drop this section,
or say why this was never implemented.

p. 71:  I'm still not 100% sure how style/roles/defaults work, as far as
what the full scope of precedence is.  It seems like there are maybe 8
different ways to define something.  It would be nice to have an example
that had all eight defined, and told you why the one that took precedence
took precedence, then said what happened if that was undefined, then if the
next was undefined, etc.

p. 71: "(see also Appendix 3.3.2 on page 12)."  Section 3.3.2 is not an
appendix.

I ran out of steam and didn't read the validation rules, but yay them being
there.

-Lucian

On Wed, Apr 15, 2015 at 7:07 AM, Frank T. Bergmann <fbe...@ca...>
wrote:

> Dear Members of the PWG,
>
> Over the past months we worked on getting the render specification into the
> official format for SBML Level 3 packages, and of course to ensure we have
> validation rules for all the bits and pieces. In time for HARMONY we
> present
> to you now a first draft that you find under:
>
> http://tinyurl.com/render-draft1
>
> and would ask for your feedback.
>
> All the best,
> Frank Bergmann,
> on behalf of the authors
>
>
>
> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live
> exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
> event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> _______________________________________________
> sbml-render mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-render
>

Dear Members of the PWG, 

Over the past months we worked on getting the render specification into the
official format for SBML Level 3 packages, and of course to ensure we have
validation rules for all the bits and pieces. In time for HARMONY we present
to you now a first draft that you find under: 

http://tinyurl.com/render-draft1

and would ask for your feedback. 

All the best, 
Frank Bergmann, 
on behalf of the authors

Hi all,

Now being informed it is sufficient for me, also because HARMONY is
approaching. For the students of GSoC the old document can still be used
to get an idea about what render is all about. Render is just one of
many things to read for them and not the main target, so there is
nothing to change at this point. I will update them a.s.a. there is a
new document.

Thanks!
Andreas

-- 
Dr. Andreas Draeger
University of California, San Diego, La Jolla, CA 92093-0412, USA
Bioengineering Dept., Systems Biology Research Group, Office #2506
Phone: +1-858-534-9717, Fax: +1-858-822-3120, twitter: @dr_drae

On Tue, 18 Mar 2014 09:03:44 -0700, Andreas Dräger wrote:
> Just today I noticed that the draft specification of the render
> extension is no longer linked from the sbml.org web site. At the first
> glance, I could also not find the PDF in the web anymore. IMHO, this is
> a bit inconvenient because we would like to use render in some Google
> Sommer of Code projects and cannot provide students with the PDF. I
> would therefore be happy to get to know the current state and release
> plan of the render specification. Fortunately, I still have a copy of
> the old PDF, but I don't know if I should give this to students at this
> time?

Regarding the distribution of the specification:

You are probably looking at the page

  http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/Rendering_%28render%29

With the last specification dated from 2011, and Frank working on an update, it seemed safer not to link to the last document, and instead leave the information about who to contact.  If you guys feel this is a poor choice, then maybe we should change it. 

MH

Hello Andreas 

I’m currently working on a new draft that is more in line with the SBML L3 Package format. Until then the current specification is still the one on: 

http://otto.bioquant.uni-heidelberg.de/sbml

I ought to have an updated draft available for HARMONY … 

cheers
Frank

On Mar 18, 2014, at 5:03 PM, Andreas Dräger <and...@en...> wrote:

> Dear Render team,
> 
> Just today I noticed that the draft specification of the render
> extension is no longer linked from the sbml.org web site. At the first
> glance, I could also not find the PDF in the web anymore. IMHO, this is
> a bit inconvenient because we would like to use render in some Google
> Sommer of Code projects and cannot provide students with the PDF. I
> would therefore be happy to get to know the current state and release
> plan of the render specification. Fortunately, I still have a copy of
> the old PDF, but I don't know if I should give this to students at this
> time?
> 
> Best regards and many thanks
> Andreas
> 
> -- 
> Dr. Andreas Draeger
> University of California, San Diego, La Jolla, CA 92093-0412, USA
> Bioengineering Dept., Systems Biology Research Group, Office #2506
> Phone: +1-858-534-9717, Fax: +1-858-822-3120, twitter: @dr_drae
> 
> 
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> sbml-render mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-render

Dear Render team,

Just today I noticed that the draft specification of the render
extension is no longer linked from the sbml.org web site. At the first
glance, I could also not find the PDF in the web anymore. IMHO, this is
a bit inconvenient because we would like to use render in some Google
Sommer of Code projects and cannot provide students with the PDF. I
would therefore be happy to get to know the current state and release
plan of the render specification. Fortunately, I still have a copy of
the old PDF, but I don't know if I should give this to students at this
time?

Best regards and many thanks
Andreas

-- 
Dr. Andreas Draeger
University of California, San Diego, La Jolla, CA 92093-0412, USA
Bioengineering Dept., Systems Biology Research Group, Office #2506
Phone: +1-858-534-9717, Fax: +1-858-822-3120, twitter: @dr_drae

Am 5/11/12 8:27 PM, schrieb Michael Hucka:
> On Thu, 10 May 2012 07:31:26 +0200, Andreas Dräger wrote:
>> My question is therefore, first, why it was actually decided not to have
>> a name attribute in addition to the id for several elements in
>> SBML-render, and second, if you have some proposal what we can do for
>> our implementation?
> I don't remember the precise reasons, but layout&  render are the two oldest packages, predating even the final L3 specification.  It probably has more than one oddity as a result of the fact that many principles were never fully worked out at the time they were first developed.
>
> These specifications are not 100% final, and small details like this could probably be adjusted.
>
>

Hi all,

In this case, I propose to let all classes from SBML-Render that have 
just an ID but no name in the specification extend AbstractNamedSBase, 
which gives the possibility to also set a name. The important point of 
this will be that then the model will be able to register links to these 
elements and take care to avoid duplicate identifiers. Otherwise, we 
would have to split the interface NamdeSBase (and AbstractNamedSBase as 
well) from JSBML's core into two distinct classes, one caring about the 
ID and a derived class that also has a name tag. This would make JSBML 
again a bit more complicated and would also cause additional effort. The 
easier way seems to be to introduce an optional name attribute on some 
Render elements. By making this optional, all existing render files 
would still be valid, no real change.

Cheers
Andreas

-- 
Dr. Andreas Dräger
University of Tuebingen
Center for Bioinformatics Tuebingen (ZBIT)
Sand 1
72076 Tübingen
Germany

Phone: +49-7071-29-78982
Fax:   +49-7071-29-5091

2012	Jan	Feb	Mar	Apr	May (4)	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2014	Jan	Feb	Mar (4)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2015	Jan	Feb	Mar	Apr (1)	May (1)	Jun	Jul	Aug	Sep	Oct	Nov (1)	Dec
2016	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec (8)
2017	Jan	Feb	Mar	Apr	May	Jun (2)	Jul	Aug	Sep (3)	Oct	Nov (1)	Dec
2018	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (1)	Sep (2)	Oct	Nov	Dec

sbml-render Mailing List for Systems Biology Markup Language (SBML)

A file format for exchanging computational models in systems biology

sbml-render — The SBML L3 Rendering package discussion list