Keith.
-- Keith Noddle Phone: +44 (0)116 223 1894 AstroGrid Project manager Fax: +44 (0)116 252 3311 Dept of Physics & Astronomy Mobile: +44 (0)7721 926 461 University of Leicester Email: ktn-at-star.le.ac.uk Leicester, UK LE1 7RH Web: http://www.astrogrid.orgReceived on 2007-10-03Z17:49:32attached mail follows:
This earlier message from John Good contains some useful suggestions for the information schema (3rd paragraph), which we might want to consider including (e.g., suggested output format for column printing, whether there can be nulls, etc.). - Doug ----
>From jcg-at-ipac.caltech.edu Fri Sep 21 08:57:28 2007
Date: Fri, 21 Sep 2007 07:55:58 -0700 From: John Good <jcg-at-ipac.caltech.edu> To: Doug Tody <dtody-at-nrao.edu> Subject: Re: Notes on TAP interface Doug - There are several arguments in support of a SimpleQuery interface. It allows potential service providers with very simple datasets (and limited resources) to provide robust search functionality through simple filtering. It is much simpler to match to datasets that are not in SQL-based systems. Even for SQL-based DBMSs, it will be easier to parse and translate than the SQL-like ADQL. Furthermore, based on what ourselves have experienced and see from other service providers (who have SQL-based infrastructure already), the vast majority of real-life queries fit this simple model. As for the information schema, IRSA has always maintained the metadata concerning catalogs in associated searchable tables. This contains, for each column the name, description, units, output format, whether the column should be included in a 'mimimum' output set, whether there are nulls, whether the column is indexed, etc. Having such extensible and searchable data has been invaluable. - John Doug Tody wrote:
> Hi John -
>
> Could you also state your opinion on
>
> 1) How important it is to have a "SimpleQuery" non-ADQL operation as
> well as the AdqlQuery, since this is a key topic.
> 2) Also, the need for something like the information schema
> subset/extension we propose, to inform advanced ADQL queries.
>
> On Thu, 20 Sep 2007, John Good wrote:
>
> > I've gone over your notes and agree with almost all of it.
> > I'm not convinced that the form you suggest for the WHERE
> > clause is all that much easier to parse than a more SQL-like
> > syntax or that it necessarily needs to be limited to AND
> > Does your syntax allow for string comparison (LIKE '%this%')
> > or generic datetime entry?
>
>
> There could well be better ways to do the WHERE parameter; as I say
> I think this is the one part of this which I am least sure about.
> The advantage of the syntax described, aside from being simple, is
> that other DAL interfaces like SSA already support range-list syntax,
> so code will aready exist to parse ranges. Range-list syntax supports
> ISO 8601 time format.
>
> I agree that it would be good to have a way to do LIKE '%this%'.
> Having anything more than AND in the same clause is not so easy,
> as then we get into parsed expressions and we may as well use ADQL.
>
>
> > It would also be simple enough to allow for an optional
> > "disposition" parameter in the Simple Query which would
> > allow it to handle big result sets asynchronously by putting
> > them in, for instance, VOSpace.
> >
> > Still, this level of functionality can be left for the ADQL
> > mode; I can certainly live with this the way it is.
>
>
> Yes, it is easy to add all these things, especially since the AdqlQuery
> operation will already have them, however we should focus on first
> defining the simplest useful SimpleQuery. The WHERE syntax is probably
> the biggest remaining issue (assuming we agree we want SimpleQuery).
>
> - Doug