DAL/TAP Response

[Keith Noddle]

Hi Ray,

Firstly, thank you for taking the time to examine this so closely - it 
helps enormously.

> Might I suggest that it is your option 1 that departs from the most 
> recent decisions of the IVOA, decisions that led to the formation of the 
> tiger team and version 0.3*?  Preserving the efforts of that group was 
> at the heart of Bob's comments before Christmas and which I was hoping 
> we could give a honest go at.
OK, I admit it - I'm worried. I cannot face the prospect of standing 
before *yet another* Interop with nothing to show about TAP. I'm trying 
to explore a different road to the same destination for TAP, but with 
the advantage that along this new road, something tangible and useful is 
almost guaranteed to emerge. The end result must match exactly the IVOA 
decisions made, it is just the path and interim deliverables that 
change. Otherwise there's no point even examining this option.

> The motivation behind the integrated approach was to ensure an 
> integrated underlying architecture.  In fact, this brings up two issues 
> I would put on a list of "issues to talk about" list:
> 
>   1.  How should the architectural approach be framed?  In the previous
>       revisions, we saw a tension between two reasonable approaches that
>       had been developed in independently coming together in TAP:
>         o  a REST-based approach (originating from GWS)
>         o  the so-called DAL2 approach (originating from DAL)
> 
>       Is there an integrated approach that does not reject the advantages
>       and progress made to date of either one?
> 
>   2.  How should should the relationship between Param-Query and ADQL be
>       presented?  Should both be presented as parallel, fundamental
>       interfaces (based on an integrated architecture) or should
>       Param-Query be defined as a layer on top of ADQL?
> 
>       The two most versions of the TAP document, I think, favored
>       different sides of this question.  In particular, in one version,
>       parts of the Param-Query interface were moved to appendices.
> 
> Splitting the spec into the two steps would appear to favor (a) the REST 
> architectural approach and (b) the choice of layering Param-Query on top 
> of ADQL.
Assuming the new TAP V1.0 + V1.1 approach, I will happily put TAP/Param 
back into the body of the document of V1.1 if that is what folk want. 
Putting it into an appendix was a convenient way to separate out 
mandatory from optional - but I was in two minds when I created the 
outlines because I knew how it would appear. However, once I'd created 
the outlines, I realised that on face value there doesn't appear to be 
much work to be done to complete V1.1 and so decided to press ahead 
hoping it would show my approach loses us nothing and gains us much.

So why change anything if I think we can do both? Because I'm not *sure* 
about doing both in parallel; I worry that there is some intangible 
tension that derails us and prevents progress. However I am sure that:

(a) we can get _something_ out by adopting the new approach
(b) it is better to build upon a solid foundation than to try to build 
everything from the ground up
(c) the next Interop is looming.

> Nevertheless, your suggestion is out there now for consideration, and 
> seeing the outlines is *very* helpful.  It might also be helpful to put 
> out an outline that shows the difference between 0.30 and 0.31.
> 
> Most importantly, though, I would like to hear people's reactions to the 
> two issues I listed above.  If we can gain some consensus on these 
> issues, then we know whether to continue with an integrated approach 
> (and benefit from progress in the fal), to split into a 2-step approach, 
> or perhaps some other option.
Agreed, discussion is most important.

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         Skype:  keithnoddle
Leicester                       Email:  ktn at star.le.ac.uk
LE1 7RH, UK                     Web:    http://www.astrogrid.org