Rethink the Constraint-based search Query from Registry interface

[Paul Harrison]

Ray Plante wrote:
> Hi Paul,
> 
> On Fri, 8 Apr 2005, Paul Harrison wrote:
> 
>>I was really arguing for I guess, although I did not say it explicitly, 
>>was that we have a separately defined registry query language, and a 
>>simple one at that without all the XML syntax. 
> 
> 
> Sorry if I misread initial note.  

my fault for starting it with such a provocative statement!

You do touch on a serious issue that
> many people have brought up, and that is having one standard depend on 
> another.  As it is, the current RI is based on an old version of ADQL.  
> This practice would probably not be so bad once our standards reached 
> recommendation status and didn't change much, but we're in the most 
> volatile period right now.  But you also mention the possibility of 
> allowing us the freedom to branch off from ADQL to support our special 
> needs.  This might be considered a Bad Thing if our special needs are 
> really just an illusion.  Personally, I don't think we have special needs 
> beyond what ADQL needs to do, but I could be convinced otherwise.  
> 

At the moment it is not so much that there is stuff that we want to do 
that cannot be expressed in ADQL, but rather that ADQL allows more than 
can be sensibly supported by the Registry Query model. e.g. subQuerySet 
so the standard has written restrictions that are not expressed formally 
in the interface WSDL. Interestingly it might be possible to express the 
  necessary restrictions on ADQL using a derived schema that used 
substitution groups...

I cannot think of any particular special requirements at the moment - 
most of the more specialized queries that I would want to do can be 
satisfied with SQL self joins - so I think that it would be good if this 
ability was mandated

> The other important point you make is the desire to drop the XML syntax.  
> That is, you would like to see a string syntax sent over the wire.  What 
> is your take, then, on the parsing issue (what I listed as "RP.1.2   It 
> should be easy to parse in multiple, commonly-used languages")?  One 
> problem with ADQL/s was that for a long time, the only parser existed in 
> C#; to convert to ADQL/x, one had to call a web service at STScI.  
> Recently (with no small effort by myself and Tom McGlynn), we wrote 
> one in Java.  ADQL/s is about the level of complexity we're going to need 
> (if you include region support).  If we go with a string syntax, we reduce 
> the number of languages that are effectively supported.  Is this worth it?  
> 

Well, in a way, you strengthen my argument with this statement! - ADQL/X 
is too complex for humans to write directly, so you need a software tool 
to convert from the human writeable version to the XML one. The problem 
with having the XML version as a parameter in the web interface is that 
every software *client* has to have the parser, so it puts a higher 
barrier in the way of potential application programmers. Granted, now 
there are some parsers available, so this should not be such a barrier 
as it has been in the last year. (Incidentally, I think that Astrogrid 
must have had a java parser for a while - Ask Martin H - so we have a 
failure of publicity and distribution of useful components in the VO 
which is a shame)


-- 
Paul Harrison
ESO Garching
www.eso.org