VOResource v0.10

[Doug Tody]

I think it is convenient for the registry entry to be self-contained.
If we were to subclass then we would have to deal not only with extensions but
with standard parameters which the service instance does not implement.
It might be useful however to indicate which parameters are standard and which
are service-specific extensions, and which are required and which are optional.

This list of service parameters is rather similar to the concept of the more
general "parameter set" which I mentioned in recent email to the Grid list.


On Tue, 22 Jun 2004, Ray Plante wrote:

> On Tue, 22 Jun 2004, Roy Williams wrote:
> > Question 1: So I publish this to some registry through forms. The forms ask
> > me if there are other parameters and I describe these (apple has the
> > description, dtaatype, ucd, etc). The end result is a piece of XML that
> > describes MY special cone search with MY special parameters. Something like
> > what you write below. Is that right?
> 
> Yes.
> 
> > Question 2: Why are the standard parameters (RA, Dec, SR) mixed up with my
> > personal paramters (apple, banana)? Has there been a thought of inheritance?
> > What would seem much better would be to say "I have a standard Cone Search
> > pus these extra parameters", rather than repeateing the standard parameters
> > every time.
> 
> We could consider this.  (ConeSearch.xsd is a working draft--alternate 
> suggested renditions are welcome.)  
> 
> That said, the current model does have the advantage one does not need to 
> recognize the resource as a ConeSearch to figure out how to call it.  For 
> example, a smart GUI or workflow engine can generate an interface on the 
> fly which includes all the possible inputs.  Nevertheless, it would be an 
> improvement if we could mark which parameters are required.  
> 
> Another advantage is that the documentation for the required parameters 
> could differ from instance to instance.  (In a previous 
> version where this info was encoded as VOTable's PARAM elements, it was 
> possible to also include supported range constraints which also could vary 
> from instance to instance.)
> 
> > Question 3: Is there an intention to define which parameters are necessary?
> > Suppose apple and banana are optional parameters? Suppose there must be at
> > least one of these? Does the registry record need to know this?
> 
> Yes, this would be an improvement, but it is not possible now.  
> 
> Any suggestions on how to encode your particular case?
> 
> cheers,
> Ray
> 
>