TAP 1.0: Substantive comments.
dtody at nrao.edu
Tue Sep 1 06:53:37 PDT 2009
Hi Francois -
The VOTable1.2 statement on this which you copy below is fine.
Basically it says that either MIME type can be used depending upon
the application to which VOTable is being applied. I agree that the
application/x-votable+xml MIME type is the most correct considering
only a VOTable file by itself without concern for how it is being used.
The issue is that TAP is a specific application of VOTable, being
a service which delivers data that often wants to be visualized in
a browser, and should say more about its specific application than
the more generic VOTable1.2 spec. As a result services will likely
be inconsistent and simple client applications are likely to work
unreliably. We can permit either MIME type and have a mechanism
for this now, but it would be better to specify a default for use
when no output FORMAT is specified (and for when "votable" output is
specified); ideally this default should be what is most appropriate
for simple browser-based Web applications. More sophisticated
applications are less of a concern as they are better able to deal
with any issues. It would also be nice if TAP behaved similarly to
the other DAL services in this respect.
If we can't agree upon this then it may be better to leave the matter
unresolved as in the current document, but if so it is sure to cause
problems for simple browser-based Web applications and queries.
On Tue, 1 Sep 2009, Francois Ochsenbein wrote:
>> On Mon, 31 Aug 2009, Tom McGlynn wrote:
>>> My concern here is that I don't think the document makes it clear
>> A similar issue is the MIME type issue (MIME type of the query
>> response votable) which was never resolved. Currently we allow either
>> "text/xml" or "application/x-votable+xml" to be returned without
>> specifying a default. We want to be able to return either, but there
>> should be a well defined default, probably text/xml. Otherwise if we
>> execute a TAP query from a browser interface it will work correctly
>> (render and display the returned table) for some services, but fail
>> (prompt for a file save) for other services. This will set a trap
>> with the application behaving unreliably, forcing client apps to
>> specify the desired MIME type with a FORMAT parameter.
>> Instead we should specify MIME="text/xml" as the default behavior while
>> allowing use of FORMAT to force return of the application MIME type.
>> Hence for example a query would render in the browser by default
>> (as for all our current data services) but a Web query form could
>> have a button to optionally direct the query response to an external
>> application such as TOPCAT under control of the browser application
> Well, I tried to make this quite explicit in the PR version of
> VOTable1.2 (section 7.3), and it tries to reflect our discussions
> at the last interop meeting:
> #In the HTTP protocol, the mime type is the value specified by the Content-Type:
> #line. The recommended mime-type describing a VOTable document is
> #application/x-votable+xml: the x- prefix indicates an experimental type, and is
> #required for non-registered media types; and the +xml suffix (defined by RFC
> #3023 section 7) indicates that the type describes a specialization of XML.
> #However the text/xml mime type is acceptable for services delivering data which
> #are expected to be visualized by humans in a browser; this mime type would
> #preferably be associated with an XSL style sheet, for a presentation of
> #well-formatted tables. It is expected that a few typical XSL style sheets will
> #be accessible from the IVOA site.
> Any disagreement wit this ?
> Francois Ochsenbein ------ Observatoire Astronomique de Strasbourg
> 11, rue de l'Universite 67000 STRASBOURG Phone: +33-(0)368 85 24 29
> Email: francois at astro.u-strasbg.fr (France) Fax: +33-(0)368 85 24 17
More information about the dal