Gets my vote. Much easier to burden the service writer than the client writer.
On Thu, 17 May 2007, Keith Noddle wrote:
> Hi Doug,
>
> > I could probably agree with all of your points except for the following:
> I'm really keen that we use what we have wherever possible. However, I
> also recognise the need to make everyone's lives as easy as possible -
> that way lies adoption of the VO! I am further convinced that consistent
> access to resource metadata - wherever and whatever their type - is
> vital and will become more so as time passes. How about this as a
> compromise:
>
> 1. TAP mandates that services return their metadata in VOResource format
> using the mechanisms defined in the VOSI
> 2. TAP mandates that the service ALSO returns those metadata in VOTable
> format in response to a metadata query
>
> Given the formats will be so similar, the burden on the service
> developer will be reasonably light - hopefully a simple XSLT translation
> will do the trick. I know we tend to try to avoid mandating too much,
> but in this case, I think there is justification.
>
>
> >
> > On Thu, 17 May 2007, Keith Noddle wrote:
> >
> >>> (5) Tables and table metadata are both tables, and the IVOA has adopted a
> >>> standard representation for tables, it is called VOTable. I believe VOTable
> >>> should be the principle way that relational schema and the table data should
> >>> be returned from TAP, although other formats may be offered by implementers.
> >>> Because tables and table metadata are unified, it means that querying the
> >>> table metadata is no different from querying table data itself.
> >> How ever the metadata are returned, the results will have to have some format.
> >> VOTable is XML as is VOResource and the VODataService extension. Given the
> >> returned VOTable will contain exactly the same information as defined by
> >> VODataService, why are we suggesting that IVOA defines yet another format
> >> (schema) to apply to the returned VOTable? VOTable is designed to return data;
> >> I am not convinced it is optimised to return medatata. Let's use what we have.
> >
> > The client application already has to support VOTable as the
> > default output format for table data queries. If native XML
> > (VOResource/VODataService) is the only format for table metadata (which
> > appears to be the suggestion here) then a client has to be prepared
> > to accept two completely different delivery formats for table data
> > and metadata, despite the fact that both are fundamentally the same,
> > i.e., tabular in nature. I think this is an unnecessary complication
> > and would break the elegant relational approach, with a uniform
> > interface for both table data and metadata, already demonstrated by
> > the SQL information_schema. Since TAP is mainly about ADQL/SQL and
> > relational queries, this would be a serious step to take.
> >
> > - Doug
> >
>
>
>
> 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
>
Guy Rixon gtr-at-ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523Received on 2007-05-17Z08:11:08