ktn at star.le.ac.uk
Fri Feb 6 05:53:36 PST 2009
Firstly, thank you for taking the time to examine this so closely - it
> 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 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
More information about the dal