Core vs Extensions in data services

[Kona Andrews]

Dear all,

This is a post on the subject of "core" vs "extensions" queries in
data services.

>From the telecon discussion, it seemed to me that the idea of what should 
be core and what should be extension was being driven by what is easy/
difficult for a service to implement (and fair enough too).  For example, 
"order by" and "group by" were suggested as extensions rather than core, 
because they are difficult to implement for distributed queries.

This raises the critical point that what is *difficult* depends very
much on the kind of service you are implementing.  For example, with
our existing data service, we could say that "order by" and "group by"
are easy and should be in the core, and the distributed joins etc should
be in the extensions, based on what is easy *for us*.  The view of core 
vs extension is subjective, and depends on the service implementation 
model you are working with.

We [AG] believe strongly that because the notion of core vs extension is a
*service-driven* notion, this distinction should NOT be made in the ADQL
language itself.  We believe that the ADQL specification should simply 
describe the full ADQL language that can be used to construct queries, 
without trying to assign different status to different parts of that 
language.

We agree that having simple "core" services and more advanced
"extension" services can be a good idea;  however, we belive strongly that
it is the *service definitions* that should define what is core and
what is extension, not the ADQL language.  Otherwise we end up repeating
the situation we have with skynode, whereby service interface and query 
language have become undesirably tangled together;  avoiding this
confusion is one of the stated aims of this working group.

The new VOResource standard provides a Capabilities mechanism that allows 
services to specify what they can do; there is no reason that the community 
could not agree a "meta-capability" called ADQL-core that covers queries 
formulated using an agreed subset of the standard ADQL language.  More 
than one such capability would be possible if required;  by using
capabilities rather than dividing the language itself into two chunks, we 
have much more flexibility re the granularity of what services can do.
For example, a service might implement the ADQL-core capability, plus a 
few other elements of ADQL;  this means that "dumb" clients can treat this
service as a pure ADQL-core service, and "smart" clients can take advantage
of its full capabilities.

This group may or may not want to define what parts of the ADQL language
should be covered by the ADQL-core capability;  however, I don't believe
that the ADQL query language specification is the right place for that 
service-level distinction to be made.

All the best,
Kona
-- 
Kona Andrews        kea at roe.ac.uk
AstroGrid Project   http://www.astrogrid.org
IfA, Royal Observatory, Blackford Hill, Edinburgh EH9 3HJ