Rethink the Constraint-based search Query from Registry interface

[Aurelien Stebe]

I also think that to depend on the evolving ADQL specifications is a bit 
annoying.
That said, the Constraint-based search query is working as it is and was 
successfully implemented by all registries (at least it seems so).
A registry specific QL could be simply a copy of the ADQL schema as it 
is now,
with a different namespace and the deletion of everything we are not 
using (select, Xmatch, subqueries, ...).
The limitations we impose on the use of XPath could even be specified in 
this new schema.
That way, we stop depending on ADQL and nobody has to change their 
implementation (except for the namespace).

cheers,
Aurelien

Paul Harrison wrote:

> 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)
>
>