Protocol confusion ? Re: SODA gripes (1): The Big One

[François Bonnarel]

Number 3 today,
>> resources, and of services input PARAMETERS. It should not contain
>> description of the dataset themselves which is the work of discovery
>> services or accessData or server side processing WEB services ( as SODA is
>> intended to be), in order to avoid confusion between the role of each module
>> in the whole DAL scheme.
> I don't think I understand this argument.  Whose confusion are you
> worried about?  Why should the description of the dataset be the job of
> discovery services?   Of course the dataset itself contains its
> metadata, and I don't think anyone was ever confused by encountering WCS
> information or the image size in a FITS header.
There is a misunderstanding. The confusion is not between Discovery 
service on one side and AccesData/SODA services on the other side but 
between them together and DataLink {link} resource.
> On the contrary: As you say, the datalink document for a dataset
> accessible through one or more SODA services will contain their
> parameter metadata.  An important part of this is the domains these
> parameters admit.  That these may or may not correspond to properties
> of the dataset in question goes without saying -- how could that ever be
> confusing?
The description of the dataset is done in the discovery protocol. The 
domain metadata for the cutout service are part of those. The cutout 
(SODA) service has to be autodescriptive that's a very important point 
in my alternative proposal.This auto-description would benefit to be 
dependant of the dataset provided as an ID parameter value and to be 
consistent with what we have in discovery protocols (basically Obscore)

On the other side I think it would be an error to put this domain 
metadata in the {link} resource response. (what you call the "Datalink 
document"). It will require several "SODA service descriptor" sections 
if we have several datasets and could be much more complex if we add 
other kind of services (future Standars or custom services). It could 
even become a mess if we have several services on several datasets
The "DataLink document" is usefull as a glue between  datasets and 
associated resources (fixed links, or services applied on the dataset, 
like SODA). General description of services (with domain metadata for 
the service) are perfectly acceptable using the "service descriptor" 
mechanism.

Please keep the "DataLink document" light and general.

Regards
François

PS: enough for today. More will come tommorrow

>
>