comments

[Wil O'Mullane]

Sorry for the delay I have been on leave ..
> 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?)
I agree but for now It is usefull to have it here. 
We could move it out in the new year when we start defining more servies.
> 
> 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.
THe only requirement for a skynode is ADQL (xml) - The SkyQL requirement was only on portals. I think this is clear in the new version (this week)
> 
> 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 :) )
Catchy is good right :)
SO in the new doc I have mode the node description up to section 7 and
the portal to the botom. We have also colapsed the levels so we just
have a Basic Sky node and Full Sky node. The 7.1 section on Basic SKyNode requirents would then be what you ask for here.

> 
> 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.)
We wanted to restrict the ADQL so an implementer was aware what might come at him. We could conside not tying these down and then agreeing them seperately but again for the sake of progress this should be done after some basic system is working.
> 
> 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.
Indeed and initally this was all in a seperate document. But I think it helps to focus nodes if you have the notion that they will be used in some specific portal. I agree many other tyoes of portal will be constructed. I shall add some clarification text to this effect..

> 
> More general comments on the content of the document:
> 
> A. 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.
In version 0.4 the COlum descriotion returns UCDs and COlumn Names and Units 
> 
> B. 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).
 colapsed to basic and full to reduce confusion iin 0.5 (next version )
> 
> C. 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 .
Yes I like that also it would work fine. 
I put this in as a requierment on the registry - leaving it in that forum how we solve it. I will add a paragraph with your soloution also

> D. 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 didi not mean all of SQL92 - only metadata queries they would be expressed in adql shall calrify. But the system needs to be aware that it will get the adql equivolent of select * from tables.


thanks for the comments  - hope we shall have time to discuss more in Strasbourg.

wil