Core vs Extensions in data services

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