I think this is a useful feature. I think you should also consider and test a variety of possible other syntax before making a decision, though. One simple alternative is to add two new fields to the segment element: <SEGMENT id="id" start="start" stop="stop" version="X.XX" label="label" extendedStart="" extendedEnd=""> Here extendedStart and extendedEnd refer to the start and end of the maximum-sized region that you could have asked for which would have returned the same set of features.
Another simple alternative which requires NO new syntax would be for the SEGMENT element to use the same format as before, but to allow it to automatically stretch the start and end coordinates and return them in the "start" and "end" fields. <SEGMENT id="id" start="extendedStart" stop="extendedStop" version="X.XX" label="label"> For example, if the user requests data for the region 1000 to 5000 but the response comes back as <SEGMENT id="id" start="500" stop="6100" version="X.XX" label="label"> then the client would be able to know that there are no additional features in the region from 500 to 6100. Older clients would probably not notice that the returned start and end were different from the requested start and end and could work as before. Clients which cache results could cache this as covering the whole region 500 to 6100 instead of just 1000 to 5000. I'm not currently involved in any DAS parsing, so I'm not likely to stay in this discussion. I just wanted to throw in this idea. Ed Erwin Affymetrix. 2009/6/29 Jonathan Warren <[email protected]> > 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. > _______________________________________________ DAS mailing list [email protected] http://lists.open-bio.org/mailman/listinfo/das
