SkyNodeInterface V0.6

[Tony Linde]

Comments on SkyNode spec: in addition to general comments below.

Firstly, I am glad we're getting to this and the generic service spec that
Wil posted in the grid list - it is much needed as a basis for future specs.

4. QI-1/2:
- this is/should be part of the service spec, not this one.

5.2:
- is the basic/full distinction valid? What if a basic service can return a
QueryCost: how is this specified? The functions that a query service can
perform should be in the metadata; they should each be namespaced and
versioned with their own specs (which might be part of this one).

5.2.1:
QI-3:
- we need a better way of signifying features than is extensible and does
not require hard-coding of metadata in the registry xsd.

QI-4/5/6...:
- these ports need to be better specified or is this in the wsdl? What is
the format of the return data? Xml? If so, we need a validating xsd.

- Tables, Columns, Formats and Functions are/should be part of the metadata
and so do not need separate calls.

QI-8:
- don't understand this. Is this saying that one query can return the data
in multiple formats or just that a query can specify the format (*should be
from a namespaced list*) it wants the data returned in? what do the abstract
class and subclasses mean? Are these Java classes or XSD classes?

QI-9:
- why do we need this? The metadata for the service should cover all this.
If it doesn't then we need to change the metadata (tables and columns are
covered).

QI-10:
- I found the name of this misleading: I assumed it was referring to the
cost of the query in runtime, memory or storage units of some kind. Can we
have an explanation of how this is done and what the calling service would
use it for?

QI-12:
- this seems to wrap several functions which are better split out: the
ability to *create* a table and populate it (whether via VOTable or via some
other ADQL query); the ability to Xmatch. If this function is saying that
VOTable and some query result can be cross-matched without loading the the
VOTable as a db table, how is this supposed to be done? Are the calculations
provided the *only* way of doing XMatching? What if someone wants to provide
the same funciton but with a better method?

QI-13:
- what is the purpose of this function? What structure is the ExecPlan? Why
do results have to come back as VOTable? There must be a more efficient way
of passing data between DBMSs. Why do we need a portal url? All the 'nodes'
should be other skynode services, shouldn't they? In which case, we only
need their ResourceIDs to identify them?
**surely all this is workflow functionality, rather than data query. If a
query service can support cross-db querying then we just need the ADQL to
reflect that**

6.:
- this is not relevant to the data query service

====

Basically, I think we need an ADQL spec and a spec which states how to
submit an ADQL query to a SkyNode (or SkyQuery service or whatever). The
service will inherit from the interface of the basic IVOA service.

The ADQL spec should include the optional capability to do multi-table and
multi-db queries, region searches, cross-matching etc. The query service, in
its metadata, needs to be able to identify which version of ADQL it can take
and which capabilities of ADQL it supports (eg multi-table and xmatch but
not multi-db and region search). Identifying all these features should be
via namespaces with associated mini-specs.

Cheers,
Tony. 


> -----Original Message-----
> From: owner-voql at eso.org [mailto:owner-voql at eso.org] On 
> Behalf Of Tony Linde
> Sent: 14 January 2004 06:09
...
> 
> The document wraps too much into a single spec. VOQL has been 
> split out but this doc still contains Open SkyQuery Portal 
> which is inappropriate as an IVOA standard; we do not need a 
> portal standard. Even if we did, it should not be included in 
> the SkyNode spec.
> 
> I understand the intention to present an architectural whole 
> but this could be done in a Note which cross-refers to the 
> individual specs.
> 
> What is the intention of the SkyNode interface? Is it to be 
> the *only* way in which any VOQL query can be submitted? Does 
> every data query service have to implement this interface? If 
> not, what others are there and where do they fit in?
> 
> Even the SkyNode interface wraps up too much: Wil has already 
> proposed a standard 'service' interface and I think this 
> needs to be worked on first before SkyNode can even be 
> considered. I think the SkyNode spec will then need to be 
> radically worked on before it can go forward even as a 
> proposed standard.