Forums

> 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