BAND question

[Anita Richards]

> Hi Alberto, Doug,
>
> ... good point. In order to tackle this and another comment received in the DAL
> session this week I'd like to put another gray box with a note to section 7.4
> which deals with ordered lists and the issue of boundaries:
>
> "Interval and range list query paramaters SHOULD be ordered monotonically.
> Interval boundaries are included in the search range. A service SHOULD return
> any record inside or just overlapping the search interval. A service SHOULD err
> on the side of inclusion thereby leaving the ultimate decision to the consumer
> whether to select it for retrieval. A service MAY truncate or compute data to
> match the exact boundaries."
>
>
> One may argue for turning the SHOULDs into MUSTs but this would give service
> providers no means to exlude items from a result which would otherwise be
> deemend unreasonable for one reason or another. One could also be more specific
> depending on the type of data (atlas vs modeled), but I'm not sure being more
> verbose is useful.
>
> Cheers,
> Markus

Yes, Markus is right; this is a good example of where we need to allow 
flexibility at present (and not make the spec too verbose either).  The 
only comments I would make are

1) "...just overlapping the search interval."
Leave out the word 'just'? As that implies that some kinds of overlaps are 
better than others, which at present is not possible to check, I think.
In any case the Bounds may be slightly broader than the useful range of 
data (at least for some ranges) so erring on the side of inclusion is the 
best default.

2) A question for future consideration (not  to delay the present model):
    What about the situation when a user wants to select data in a workflow
    for immediate passing to another application, rather than human
    judgement and selection? In that case, you might want to select
    only data entirely ovelapping the desired range? Or falling entirely
    within it? Or some other criteria...
    Is this best done in a _second_ step separate from the model? I feel
    that is the best solution, since the exact demands may vary, so the
    important issue is that the model should allow enough detailed metadata
    to be passed with the data.
    Some data may fail to be selected either because it does not directly
    meet the specs, or because it lacks enough metadata to know whethr it
    does or not.  That might be what some users want (e.g. for popular
    bright objects) but other users would be happy to get any data and
    decide for themselves.  Markus's solution covers the latter case now
    and allows extension.

thanks
a

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dr. Anita M. S. Richards, AstroGrid Astronomer
MERLIN/VLBI National Facility, University of Manchester, 
Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K. 
tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).