[DAS2] Why use URIs for feature IDs?

[Andrew Dalke]

I'm going to incur the possibility of pitchforks here.. :)

Me:
> Yes.  I like URLs.  I've been so in favor of URLs that until
> this morning I had in the spec that the "id" *is* the URL.
> There was no short form for the URL.  (still /is/ no short form
> since it hasn't changed ;)
>

> I'm now going to be either stubborn or irritating or both.
> Why have an id at all?  That is, why at all have a short string
> (say of the form /[A-Za-z0-9_]/ when the URL is there and
> meets all the functional requirements of an identifier?

Here's the change - or not change since it reflects the
current spec.

Features and types have a single "id".  That id is a uri
in all its glory.

Referring to Dave's email, yes, special characters are
included - this is a uri.  Looking at
   http://blog.bitflux.ch/wiki/GetElementById_Pitfalls
the getElementById refers to the attribute with type "ID"
which happens to be named "id" for XHTML and SVG.  Given
   http://www.w3.org/TR/xml-id/
I have added xml:id as a common attribute for all of the
DAS items for independent and optional identification of
an element in a document.

There is no short-form id for features and types.  Queries
are done using the full URL.  For example, to find all elements
of type "http://www.example.com/das2/human/1/type/T12345" the
query string (assuming the query url is ".../1/feature_search.cgi")

   http://www.example.com/das2/human/1/feature_search.cgi?
type=http%3A%2F%2Fwww.example.com%2Fdas2%2Fhuman%2F1%2Ftype%2FT12345

The single and sole exception is for range queries.  Each
segment has a URL and a "name" attribute.  This name is a
unique short-form identifier used for range queries.  The name is
of the form /[A-Za-z_][A-Za-z_0-9]*/ .  To do a range query
for all features on a segment with name Chr1 and range 50 to 100 use
the format "X/50:100" and the query looks like

   http://www.example.com/das2/human/1/feature_search.cgi?
overlaps=X%2F50%3A100

The reason for this exception is three-fold:
   - the syntax for merging the URL and two/three fields became ugly
   - Gregg wants to send multiple ranges at a time, if the client
       knows enough about what it has already
   - the client may consult one of several reference servers given
      the coordinate system for the annotations.

These do not hold for feature types (features are independent
objects; there will be at most a handful in most servers; the
types are specific to the given set of features)

					Andrew
					dalke at dalkescientific.com