Core vs Extensions in data services

[Yuji SHIRASAKI]

Dear all,

In my view, the primary purpose of this group is to define a 
universal language that is applicable to all the data service.

The "Capabilities mechanism" may provide a way to know what 
part of full language spec is suppported, but it should be
used to enhance the service capability.

The minimum service capability should be defined universally 
so that a client can use the minimum capability with a small 
effort (without quering the capability).

So, I believe the minimum language capability (ADQL Core) should
be defined in the ADQL specification, and we should enforce all
the VO compliant serverce to support the minimum spec.

Secondary purpose of this group is to define a guideline to 
exntend the ADQL Core.

A service provider may extends the language spec in a different 
way to provide extra functionalities for a local community, but
in that case such extension will be used only in the local 
comunity and may not be used in the wider comunity.

Following the guideline to extend the ADQL core, it becomes 
possible to inform the supported languge spec to the wider 
comunity by the "Capabilities mechanism".

If the extentions are made by an arbitrary manner on service by 
service basis, it become difficult for a client to understand 
the capability.

I don't see any reasonable reason or advantage to put the ADQL 
core and extensions out of the ADQL spec.

Yuji Shirasaki.

From: kea at roe.ac.uk (Kona Andrews)
Subject: Core vs Extensions in data services
Date: Wed, 1 Nov 2006 10:33:22 +0000

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