[DAS2] alternate formats

[Andrew Dalke]

If you've read the updated schema definitions you saw
I've added the following comment in the CAPABILITY

   # Format names which can be passed to the query_uri.
   # The names are type dependent.  At present the
   # only reserved names are for the 'features' capability.
   # These are: das2xml, count, uris
   format*,


We talked about this in the UK I think, and I mentioned
it to people here.  The 'count' format returns the count
of features which would be returned for a given query.

This is a single line containing the integer followed by
a newline.  The content-type of the document is text/plain .

For example, to get the number of all the features on
the server

Request:

http://www.example.com/das2/mus/v22/features?format=count

Response:

Content-Type: text/plain

129254


I will add this format description to the spec.


When does the server need to declare that it implements
a given document type?  My thought is that if the format
list is not specified then the server must implement
'das2xml' and 'count' formats.  If it doesn't implement
the 'count' format then it needs to declare the complete
list of what it does support.


In addition I'll describe here the 'uris' format.  It is
a document of content-type text/plain containing the
matching feature URIs, one per line.  For example,

file://Users/dalke/ucla/feature/Affymetrix_U133_X3P: 
Hs.21346.0.A1_3p_a_at
file://Users/dalke/ucla/feature/Affymetrix_U133_X3P: 
Hs.21346.0.A1_3p_x_at
file://Users/dalke/ucla/feature/Affymetrix_U133_X3P: 
Hs.21346.1.S1_3p_x_at
file://Users/dalke/ucla/feature/Affymetrix_U133_X3P: 
Hs.21346.2.S1_3p_x_at
file://Users/dalke/ucla/feature/Affymetrix_U133_X3P: 
Hs.21346.3.S1_3p_x_at
file://Users/dalke/ucla/feature/Affymetrix_U133_X3P:Hs.271468.0.S1_3p_at


(I feel like it should implement an xml:base scheme to reduce
the amount of traffic.)

The idea is that a client can request the URIs only, eg,
to do more complex boolean-esque searches by doing simpler
ones on the server and combining the results in client space.
For another example, if the client already knows the feature
data for a URI then it doesn't need to download the data again.
So it gets a list of URIs then only fetches the ones it
does not know about.

This requires HTTP/1.1 pipelining for good performance.

Because there are no clients which want it, because I'm not
certain on the format, and because of the lack of pipelining
in the existing servers, I will not document this format.  I'll
just leave it as a reserved format name.

					Andrew
					dalke at dalkescientific.com