Core vs Extensions in data services
kea at roe.ac.uk
Wed Nov 1 02:33:22 PST 2006
This is a post on the subject of "core" vs "extensions" queries in
>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
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 Andrews kea at roe.ac.uk
AstroGrid Project http://www.astrogrid.org
IfA, Royal Observatory, Blackford Hill, Edinburgh EH9 3HJ
More information about the voql-teg