[DAS2] stylesheets meeting

[Andrew Dalke]

I met yesterday afternoon with Andreas Prlic, Andreas Kahari and
Eugene Kulesha to get information about their stylesheet needs.
Ed said he would work more on the spec and this should provide
some relevant information.

We ended up talking about the stylesheet using a sort of CSS
approach.  There are selectors (feature uri, type uri, etc.)
and properties (color, glyph shape, ...).  Some of the properties
inherit/cascade and others don't.  There's nothing new in this;
we talked about it during the 2nd sprint.

The details of inheritance prove tricky.  For example, consider

[ Feature A ]   ---- is of ---> [ Type 1 ]
     |
   contains
     |
[ Feature B ]   ---- is of ---> [ Type 2 ]

where each feature and type has a style sheet.  The property
(say "color") for Feature B is determined first by the stylesheet
for Feature B, then that of Type 2.  If still not present,
does it come from the parent(s) of Feature B and the parent's
type?

Given as that requires correct traversal in the face of multiple
inheritance, I'll now argue "no".  Even though this is an
effectively solved problem in OO programming ("C3 method resolution
order", from Dylan and also used in Python, Perl6, and others).
It's complex enough to make it unjustifiable.

The selectors people wanted are:
    - the feature type, based on its uri
    - the feature itself, based on its uri
    - view type, that is, "2D" vs "3D".  Akin to "screen", "paper,
        in CSS.  Andreas P's DAS-based structure viewer uses
        very different stylings ("ribbon", "vdw") than sequence.

Note: only "and" selections are requested.  There seems to be no
need for selection like "features of type T1 which are descended
from feature F2"

Other possibilities are:
    - selectors based on the type ontology uri
    - application-specific styles (but this is probably handled
         best through properties and not though a selector; on the other
         hand, it would enable workarounds for app-specific bugs)
    - level of detail (but Eugene didn't even know this option existed
         in DAS1, so perhaps it's not needed for DAS2)
    - support for overrides in case of stylesheet conflicts (user
       overrides server overrides application, most recent definition
       overrides previous)

For the view and the application selectors a space separated list
seems reasonable, as
    view="2D 3D" ... color as yellow
meaning that for 2D and 3D to draw the feature in yellow.  Or just
leave out the selector.

One question was how to find the stylesheet.  They can be listed in
the SOURCES document but I was thinking they could also be listed
in the FEATURES response, as

<FEATURES xmlns="http:// ... /">
   <link rel="das-stylesheet" type="application/x-das-stylesheet"
          href="http://example.com/stylesheet">


Another question is the format of that selection language.
That was quickly answered: "in XML".

I brought up Ed's comment about (if I understand correctly) making
the shape language a bit more abstract.  For example, in DAS1
there's a GLYPH called "PRIMERS", while the others are names like
"EX" and "ARROW".  The general view is that this level of abstraction
isn't useful.  Andreas Prlic summarized it nicely as (reworded) "the
goal of a stylesheet is to make thing concrete".  Though perhaps an
SVG-style set of drawing commands may be useful.

That said, there may be a few things which need a more domain-specific
name.  The example which came up is in color.  EBI has "contig blue"
as a color name.  Are there other colors like that?

On the topic of colors, the desired colors are the CSS color names
(though in-house they also have the X11 names) and the CSS-style
#color #selection, as #0FF for cyan.  The #RGB and #RRGGBB color
names are sufficient.  Other CSS variation, like rgb(255, 0, 0) and
rgb(10%, 45%, 82%) are not needed.

In the meeting I mentioned alpha/opacity values in CSS as #RGBA and
#RRGGBBAA.  In writing these notes up I see that CSS does not support
that syntax.  Alpha is a "wouldn't it be cool if .." feature and not
one which is needed or specifically requested.

I outlined support for more complex font information for DAS2.
Feedback here say that's not important.  There's no desire to change
the font size, style, etc.  Nor desire for super/subscript, underscore,
italics, bold, condensed, etc.

I asked about standardizing the drawing model so there is more
consistency between different viewers.  For example, if there is
a glyph and a piece of text, where is the text drawn in relationship
to the glpyh?  Does the height of the glyph include both?  There
was no desire for this.

On the other hand, a current user-specified option is where to
draw the text, which corresponds to a stylesheet override.

What they want is support for plots and color gradients.  See the
"Gradient" and "TilingArray" entries at

http://www.ensembl.org/Homo_sapiens/contigview?conf_script=contigview; 
vc_start=25422500;vc_end=25447499;region=17; 
add_das_source=(name=Gradient+url=http://das.ensembl.org/ 
das+dsn=hydraeuf_00001350+type=ensembl_location_chromosome+stylesheet=y+ 
score=c+fg_merge=a+fg_grades=50+fg_data=l+fg_max=310+fg_min= 
-143+active=1);add_das_source=(name=TilingArray+url=http:// 
das.ensembl.org/ 
das+dsn=hydraeuf_00001350+type=ensembl_location_chromosome+stylesheet=y+ 
score=s+fg_merge=m+active=1

I can think of several ways to handle that.  One is to declare a feature
for the entire chromosome, as

<FEATURE id="asdfasdf">
   <LOC segment="../chromosome1" />
   <extension:tiling_data href="http://somewhere/else" />
</FEATURE>

and viewers can use some agreed upon protocol to get the right data from
somewhere/else.

Another is

<FEATURE id="asdfasdf">
   <LOC segment="../chromosome1" />
   <extension:tiling_data>
R0lGODdhOABkAPMAABq15RaU14za5O3391660P////7//vz+/gAAAOCP4XJgv// 
10AAAAACP4XRM
j+F1ICwAAAAAOABkAAAE/xDJSau9OGtZuv9gKI4kyZVoqorn6r4sAs90S9+pje8x7/e/ 
YEcn3BGL
tyNyply+ms4VNJqTUZPWKzOrfXK70i+4OvaWXdOzJ60usNXvc7w8H9fB925eu7/ 
2qX9RgU6DS4VI
h0WJQotBjT+PPpE8k0ZibSGVOJpYlm5DkJdhblaiMH1ZFKGba6Cmo1gTQ4GNspuvSZS4mJw1 
u229
W5gowae/ 
OwYDBmZUAwIBBAMHsE7OANcA0dPExzMHzwAB4tkC2ybdMALX4uMBAgTmQEXJ7AHW2NnK
I48D9QIGyQhgczdgHzoVBwiwK+dhgMAA5OKtOZiin7h/IL4pJCgvyDd3EtQ/ 
HJBm0Em8Ac4KqqiU
7Nm4aGSqqau3juG5ag8hEpwpoAQ/ 
gQNhFpipsuMPA+rWgfSQEEDPkkWahhP6YUC2kLOQOJyKtR8A
rKS0PsQY4hk8qEK2Xiva8JrNTBRRfMNGVSO5m0je4SMANBtfsGGR2A23ly9buDIFvAPKV8Bh 
xCZR
OlOMEvDEMwYOaPYZd0XmyYv5EngLgt9iiISvjU6JVgg4fAN1ulsGuYjFdkrZUS3dGYVLcY0d 
aybZ
Oqpmy8WH8VaOl3lt5x+KMYMevTegDdiza7cQAQA7
   </extension:tiling_data>
</FEATURE>

with an agreed upon definition of how to interpret the in-line data.
But for the entire genome this could be rather big.

Another is to break it down into parts, as

<FEATURE id="a00001">
  <LOC segment="../chromosome1" range="0:10000">
   ... data for the first 10,000 bases ...
</FEATURE>
<FEATURE id="a00002">
  <LOC segment="../chromosome1" range="10000:20000">
   ... data for the second 10,000 bases ...
</FEATURE>
   ...

There is already the need for displaying images on the display, but
the current use is to click on a point to bring up an image and not
showing the image as a glyph.  The current solution is a hack,
embedding HTML in the NOTE field.  Only a couple of HTML elements are
supported.

This can easily me moved into a property or a local extension
in DAS2.

If viewer does not understand one of the extensions, what does
it display?

There are two things in DAS1 which I don't know well enough to ask
reasonable questions.  One is the BUMP, which I think specifies if
multiple glyphs of the same type may overlap.  I think Eugene said
they wanted more control over that, like limiting to at most 5
overlaps.

Another is the GROUP, which in DAS1 was used to merge multiple
feature types into a single track.  Quoting from the DAS1 spec

     The canonical example is the CDS, exons and introns of a
     transcribed gene, which logically belong together.

DAS1 has specialized stylesheet language for depicting groups.
DAS2 uses hierarchical features instead.  Does/can DAS2
do the right thing for depicting those?

I think I've covered the major points.  Please chime in if I've
missed anything relevant.

					Andrew
					dalke at dalkescientific.com