[DAS2] Adding an optional "searchable" attribute to <TYPE> element

[Helt,Gregg]

In the last DAS/2 teleconference I brought up again the idea of an
optional "searchable" or "filter" attribute for the <TYPE> elements
returned from a types query -- if present and "false", then that type
should not be used in a feature query filter.  Here are snippets about
this from discussion during the last code sprint (I've tried to strip it
down to just the relevant parts):

> -----Original Message-----
> Sent: Monday, August 21, 2006 2:43 PM
> To: DAS/2
> Subject: [DAS2] Notes from the weekly DAS/2 teleconference, 21 Aug
2006
> 
> Notes from the weekly DAS/2 teleconference, 21 Aug 2006
> Note taker: Steve Chervitz
> 
... 
> [The note taker apologizes for attending late (~30min)]
> 
> gh: could a server in the types doc restrict the types. just say
> 'transcripts'?
> ls: yes. if not going to allow for searching for feature, only via
> parent, then types doc should only include parent.
> 
> gh: types doc specifies which types you can query on.
> ls: ontology gives you access to all types that might come back
> ad: and how to depict them.
> gh: yes, but it can be restrictive of the types.
> ad: what does client do to display it?
> gh: implies we separate out style into stylesheet info again.
> no one is serving or using, so we can change w/o major impl changes.
> ad: type doc ties a feature to ontology, how to display it, and
> includes this extra source field.
> gh: types doc has all types server contains but tags as to what the
> server allows searching on.
> 
> ad: feels weird. can't see why i'd want to do in my server.
> bo: better than limiting the types doc, just have a searchable field.
> ad: easy
> gh: if you don't say no, then it's searchable. this is backwards
> compatible.
> 
...
...
> 
> ad: range and non-range filters must both be true for a given feature
> 
> gh: ok, as long as we  can say in types doc that some types are not
> filtered.
> 
...
> [A] andrew will add searchable flag to type document
...

The motivation for this addition to the spec is to allow a server to
restrict what feature types a client can use for query _filtering_,
while still allowing these types of features to be returned from feature
queries and their display properties to be described in stylesheets.
This restriction is important for my server implementation to make full
use of ontologies in describing feature types.  And in the more general
case, I think it will be good for visualization clients.  To use a
concrete example, in a GUI I don't want to have to make the user choose
between requesting "genscan-transcript", "genscan-exon",
"genscan-intron", or some combination of these types to make sure they
get all the "genscan" annotation information -- this is a recipe for
confusion.  Now a smart client that fully understands the sequence
ontology could automatically simplify this for the user, but I don't
expect most client implementations to be so smart -- after all, one of
our goals is to have a low threshold for simple client and server
implementations.  In this example it would be much easier for the server
to just specify that "genscan-exon" and "genscan-intron" are not usable
in a query filter, and the client just shows "genscan-transcript" in the
query options.

This change in the spec is backward compatible, since <TYPE> elements
without a "searchable" attribute would by default be searchable.  It
should be easy for clients to implement, and servers can implement it or
ignore it.

	Gregg