DAL/TAP

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