comments

Some comments on the latest version of the IVOA SkyNode Interface (apologies for cross-posting but there are registry issues in this).

First comment is really about the scope of the document. I think it really encompasses three or four separate areas that ought to be addressed each in its own recommendation:

1. Section 4 refers to a 'Standard VO Interface', ie the minimum interface that *any* service must meet to be registered on the VO. (I guess this document would fit into the DAL stream of IVOA?)
2. The sections 5 & 6, ADQL and SkyQL, ought to be a single document under the VOQL stream: SkyQL can be subsumed under the ADQL document as the string representation of an ADQL query. I think the ability to accept a SkyQL string ought to be optional for a skynode, while ADQL is mandatory: xml is much easier to decode than straight text. Any portal which allows the user to enter text queries ought to translate it to ADQL before submitting to a skynode.
3. Section 8, SkyNode Interface, ought to specify the minimum interface that *any* sky service must meet to be registered on the VO. Note: the new resource schema devised by Ray and me refers to a SkyService, but I'd be happy to accept SkyNode as a name (much more catchy :) )
4. There are references in the document to query functions: REGION and XMATCH. We should think about whether these should each be addressed by simple single recommendations or all included in the ADQL one. (Also part of the VOQL stream.)
5. Section 7, SkyQuery Portal: this is certainly separate from the above two concepts but I don't think it really needs to be an IVOA standard. It will be up to individual projects how they construct portals for users.

More general comments on the content of the document:

1. ADQL needs some means of identifying both column names and UCDs, along the lines of my example at http://www.ivoa.net/twiki/bin/view/IVOA/TonyOnUCDs#Example_query . See the rest of that document for the reason why.
2. I find the explanation of the different levels very confusing. I assume that you're trying to identify how complex a query that a given skynode can handle. Is it wise to second guess which combination of functions a service will choose to implement? Maybe we need some way to identify the functions offered: a list of namespace defined enumerated list of functions (so some functions coould be namespaced from the VOQL recommendation above, others namespaced for that specific service).
3. I like the idea of using, in the short term, the ShortName as the unique identifier of mirrored datasets, but see also my idea for a more complex Relationship type in http://ivoa.net/forum/registry/0440.htm .
4. re QI-19: I don't see any benefit to adding the need to accept SQL-92 queries as well as ADQL ones. This might be an option which some skynodes offer but it should not be mandatory. It is enough for each skynode to translate ADQL into its own query language without also having to do so for SkyQL and ADQL.

I'm impressed with the amount of work that has gone into this document and hope my comments help.

Cheers,
Tony.

__

Tony Linde                       Phone:  +44 (0)116 223 1292
AstroGrid Project Manager        Fax:    +44 (0)116 252 3311
Dept of Physics & Astronomy      Mobile: +44 (0)7753 603356
University of Leicester          Email:  ael-at-star.le.ac.uk
Leicester, UK   LE1 7RH          Web:    http://www.astrogrid.org