[DAS] next "feature" for 1.6 spec

[Jonathan Warren]

Another feature we would like to add to the current 1.6 spec is the  
ability for a server to return the next feature both left and right of  
the current region if they exist but are out the currently selected  
range.
This would not need a new command, but will be specified in the spec  
as a valid response to the features cmd.

so if a user specifies chr1:1000,2000 the server can return something  
like this:
<SEGMENT id="id" start="start" stop="stop" version="X.XX" label="label">
//minimal information about the next feature in a minimal feature  
element to include location so the client knows where the next region  
of interest for this das source is.
//if the current region has no features showing then these features  
can be returned, but as they are outside the asked for range of the  
client they will not be displayed (but can be used to have a next left  
or next right button on the client.
<FEATURE id="id">
//NEXTLEFT as the type id rather than what the type id would be if in  
the normal region.
          <TYPE id="NEXTLEFT" >type label</TYPE>
          <START> 20 </START>
          <END> 30</END>
       </FEATURE>
<FEATURE id="id">
          <TYPE id="NEXTRIGHT" >type label</TYPE>
          <START> 3000</START>
          <END> 3050 </END>
       </FEATURE>
//the rest of the response as normal if features for this region exist
       <FEATURE id="id" label="label">
          <TYPE id="id" category="category" reference="yes|no"  
cvId="SO:1234">type label</TYPE>
          <METHOD id="id" cvId="ECO:5678"> method label </METHOD>
          <START> start </START>
          <END> end </END>
          <SCORE> [X.XX|-] </SCORE>
          <ORIENTATION> [0|-|+] </ORIENTATION>
          <PHASE> [0|1|2|-]</PHASE>
          <NOTE> note text </NOTE>
          <LINK href="url"> link text </LINK>
          <TARGET id="id" start="x" stop="y"> target name </TARGET>
          <PART id="child id1" />
          <PART id="child id2" />
       </FEATURE>
       <FEATURE id="child id1" label="child label">
          ...
       </FEATURE>
       <FEATURE id="child id2" label="child label">
          ...
       </FEATURE>
       ...
   </SEGMENT>



This ability would be an optional one, but we at the sanger, EBI  and  
Lincoln are very keen on this and see a great need and demand for it.  
It's especially useful for when there are no features returned for a  
region, for sparse data sources and for testing DAS sources in  
clients. There maybe a performance hit to implement this by the server  
and this is another reason why this response would be optional.

What do other people think?

Cheers

Jonathan.


Jonathan Warren
Senior Developer and DAS coordinator for the Sanger
jw12 at sanger.ac.uk








-- 
 The Wellcome Trust Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE.