On 15 Sep 2009, at 15:19, Thomas Down wrote:
Capabilities are stated in the sources document:
<CAPABILITY type="das1:maxbins" />
Ah, interesting. I'd seen that, of course, but hadn't explicitly
linked this with the idea of capabilities as listed in the X-DAS-
Capabilities header (although of course it makes a lot more sense to
have one set of capability metadata, rather than two!). There are a
couple of issues here:
1. The SOURCES examples all say "das command" in the
type attribute of the CAPABILITY element, whereas many of the
capabilities don't actually map to commands. I notice that the
latest DAS1.6 draft does give an example to clarify this.
2. X-DAS-Capabilities entries are versioned whereas
SOURCES capabilities aren't, which makes them look rather different.
(and I note that the 1.6 spec is bumping up the version numbers on
some of the existing capabilities...)
How about versioning capabilities in SOURCES, e.g.:
<CAPABILITY type="features" version="1.1" query_uri="http://noranti.derkholm.net/das/mydata/features
" />
<CAPABILITY type="maxbins" version="1.0" />
Assume any missing version attributes are "1.0" and everything
should be backwards compatible.
Indeed I did increment the version, just because it seemed the right
thing to do. However as far as I am aware these per-capability
versions are totally superfluous when taken in context with the X-DAS-
Version header, i.e. we do NOT want to make it possible to implement
DAS 1.6 and features 1.0, for example. This could create a whole world
of pain!
IMO the per-capability version is unnecessary and confusing. ProServer
does use it internally, but that can be easily changed. Getting rid of
it would make the spec less confusing, but will of course break things
that depend on the current format (if there are any).
What do others think?
The only snag is that right now you have to parse all sources.
Technically both the registry and proserver allow you do do:
http://www.ebi.ac.uk/das-srv/genomicdas/das/sources/eqtl_rat_cis_fat
But IIRC I didn't include this in the spec to keep things simple.
If this isn't specified yet, how about allowing:
http://www.ebi.ac.uk/das-srv/genomicdas/das/eqtl_rat_cis_fat/sources
?
Then it's possible to stick with the model of passing a single URI
around to refer to a "DAS datasource", and stick a command on the
end of it to get the data you're after.
Well, the reason we didn't use this format is simply that it doesn't
"read" well, if only because "sources" is plural. What would perhaps
make sense, and which would allow for quickly 'pinging' a source for
other similar uses, is to use this URL format:
http://www.ebi.ac.uk/das-srv/genomicdas/das/eqtl_rat_cis_fat
Again, this is what seems most 'sensible' to me but I am happy to go
with the consensus.
_______________________________________________
DAS mailing list
[email protected]
http://lists.open-bio.org/mailman/listinfo/das
