TAP: Summary

Guy Rixon gtr at ast.cam.ac.uk
Tue May 5 09:00:36 PDT 2009


Keith,

the problem with this is that revisions to VODataService are extremely  
disruptive and expensive.
Each time we reissue that schema, we have to fix all the registries.  
some of the services and many
of the clients. Therefore, we want to avoid a need for VODataService  
1.2 if at all possible. The
description of primary and foreign keys would be better done in  
VODataService 1.1 or
  postponed for a long time - more TAP 2.0 than 1.1.

Cheers,
Guy


On 5 May 2009, at 16:50, Keith Noddle wrote:

> Chaps,
>
> I've been overwhelmed (figuratively and literally) by the sheer  
> volume and depth of discussion that has gone into TAP of late; thank  
> you one and all. We have under three weeks remaining until the  
> Strasbourg Interop and I think everyone is agreed: we MUST have TAP  
> ready to take the next step in the standards process at the end of  
> that meeting.
>
> My roadmap for TAP is as follows:
>
> * Review and categorise remaining discussion points
> * Anything that is not absolutely critical to TAP V1.0 should be
>  moved to TAP V1.1
> * Discuss and reach agreement on TAP V1.0 points
> * Publish TAP V0.5 before Strasbourg
> * Discuss details in Strasbourg
> * Move TAP forwards in the standards process very soon after the
>  Interop with the aim of getting a recommended standard in the
>  weeks following the meeting
>
> =====================================================
>
> Bigger brains than mine have been discussing issues I confess I find  
> hard to follow. However, as an adherent of Occam's Razor, I find  
> myself agreeing with Roy, Doug and Pat: now is the time to keep  
> things as simple as possible (but no simpler!). With that in mind,  
> it seems to me the following is the list of points outstanding:
>
> V1.0:
> • Sync column metadata decisions and VODataService
> • FIELD/PARAM format attribute (VOTable V1.2)
> • Articulate scope and role of the parameter query
>
> V1.1:
> • UTYPE in queries
> • VOSpace integration
> • Supported ADQL function capabilities
> • Extend TAP_SCHEMA and VODataService to describe primary and
>  foreign keys
> • Tableset metadata
>
> Note that I have arbitrarily allocated each issue to a version -  
> please feel free to amend this list. Hopefully I'm somewhere near,  
> so I therefore ask that we *focus heavily on the V1.0 issues* and  
> return to the others post TAP V1.0 reaching REC. At least itemising  
> everything on the mailing list means nothing should be lost.
>
> One last push, then beers in Strasbourg!
>
> 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



More information about the dal mailing list