DAL/TAP

[Keith Noddle]

Dear DALers and UWSers,

I have deliberately been quiet re: TAP since last autumn to allow the 
dust to settle and mature reflection to take place. Clearly we have a 
wide range of table access requirements and it is my responsibility to 
ensure they are all equitably met.

After much thinking, discussion and water-testing regarding TAP I 
believe I have a proposal that meets the needs of all concerned and 
which will deliver solutions to table access in general that we can all 
support. My thinking is as follows:

(A) We have misled ourselves by calling parametrised table access 
SimpleTAP (it was called STAP a long time back you may recall). That led 
to the development of the VOQL-WG STAP proposal that (correctly if with 
hindsight, misguidedly) adhered closely to the other "Simple" protocols 
but which was rejected at Beijing. Henceforth, I propose that 
parametrised table access be known as "TAP/Param" and we drop all 
reference to the word "Simple"

(B) For completeness, I shall call table access using ADQL: "TAP/QL"

(C) By trying to include parametrised access along with ADQL access in 
the same specification, we inadvertently put two sets of requirements 
together that are in many ways incompatible - how much time have we 
spent gently circling the issues of synchronous/asynchronous access, 
staged versus streamed result returns etc?

I therefore propose that we separate the two table access mechanisms 
into separate standards: TAP/Param and TAP/QL and that we progress them 
independently, each unencumbered by the sometimes incompatible 
requirements of the other. However, there are obvious common areas 
between the two (output formats spring to mind) that both must specify 
but which are easy to agree. Hence my proposal has two qualifications:

(1) We include in both specifications a Contract that defines the 
required common areas (such as output formats)

(2) We include a Statements of Intent to: "endeavour to conflate the two 
specifications into one as part of the definition of TAP V2.0".

I realise that at first glance this appears to double our workload, but 
in practise I believe it will clear the logjam - we've spent far too 
long on this already and without some radical change, I don't foresee 
comfortable resolution any time soon. Qualification (1) above will not 
involve much extra work (mostly an exercise in documentation) whilst 
Qualification (2) will allow us to assess both standards in operation 
and decide the best way to harmonise the them once we know in practise 
how they work. Essentially I want to define a standard based upon 
working practise: in this I adhere to the observations of Marshall Rose, 
"The Pied Piper of OSI" :-)

I want to make progress before the Trieste Interop so that we have 
details to discuss, not principles to agree and I believe taking this 
approach will allow us to do so.

Comments?

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