[TAP] draft 0.42 (cleanup toward 0.5)

[Douglas Tody]

I did a quick test with firefox, changing a cone search service to
return either "application/x-votable+xml" or "text/x-votable+xml"
(both were tried) instead of "text/xml;content=x-votable" as specified
by the SCS standard.  Firefox 3 popped up a dialog asking me what to
do with the file.  Hence while an external application like topcat
could be configured to view the file, it does not appear that either
of these suggested MIME types permit direct rendering of votable XML
in a browser.


On Sat, 16 May 2009, Douglas Tody wrote:

> On Fri, 15 May 2009, Patrick Dowler wrote:
>
>> There's the catch: if you use text/xml;content=x-votable the claim in the
>> rfc is that mime dispatch will (should) ignore the parameter and dispatch 
>> to
>> the app responsible for text/xml, but if you use text/x-votable+xml then it
>> will dispatch to the app configured for that mimetype, and can dispatch to 
>> a
>> generic XML app if no specific one is known.
>
> What would be ideal would be if the votable is rendered using the
> browser's builtin XML handler by default (or a stylesheet if provided),
> but can optionally be configured to invoke an external application.
> If it is not possible to have both I would choose builtin browser
> rendering in order to easily support webapps.
>
> If the +xml option works that might be the best option.  We should
> verify though that this permits default XML rendering before changing
> the query response base MIME type to something other than the text/xml
> base type currently used in all our services.  Otherwise if we use a
> browser to issue a TAP query (as in almost any webapp) then the default
> VOTable query response will not be directly viewable and the poor user
> will instead get a popup asking to save the query response to a file.
> The only way around this would be to have the service explicitly
> render the response as HTML, which would be an unfortunate thing to
> require to be able to support common web applications.  Most current
> services do not support the HTML output option since we have gotten
> used to having XML rendering capabilities in the browser.
>
> 	- Doug
>
>
>
>
> On Fri, 15 May 2009, Patrick Dowler wrote:
>
>> 
>> 
>> OK, now I had to go read the RFC on a sunny friday afternoon :-(
>> 
>> 
>> http://tools.ietf.org/html/rfc3023 (note: it's not 3032 :-)
>> 
>> 
>> Section 7 talks about the +xml naming convention for new XML-based media
>> types and, as Mark pointed out, A.6 (most of A in fact) comes down against
>> parameterising to describe sub-type, mainly because MIME dispatch does not
>> take parameters into account.
>> 
>> 
>> So, it looks to me that text/x-votable+xml would be the best choice; see
>> below for reasons.
>> 
>> 
>> Pat
>> 
>> 
>> On Friday 15 May 2009 13:13:43 you wrote:
>> > Hi Mark, Pat -
>> >
>> > I must have missed this earlier. I am pretty sure that the
>> > parameterized syntax is legal, although it is less commonly seen (I
>> > have also seen this in OpenGIS for example). The advantage is that
>> > if we parameterize text/xml to specify the type of content in the XML
>> > then it is still a text/xml document, and can be processed as such by
>> > common applications such as browsers, which will typically render and
>> 
>> 
>> My interpretation of the RFC is that this should be true of
>> text/something+xml as well... the whole intent of the +xml suffix is to
>> enable generic xml processing not anticipated for the specific type.
>> 
>> 
>> > Hence in an interface like SSA text/xml with a votable subformat is
>> > used for the query response, but application/x-votable+xml is used
>> > for the spectrum if it is returned as a VOTable.
>> 
>> 
>> 
>> > In the case of TAP there is no such distinction and no compelling
>> > case to go either way. If we care about directly viewing the VOTable
>> > XML in a browser, text/xml would be preferred. If we are happy
>> 
>> 
>> The RFC also suggests text base type if the content can be plausibly viewed
>> by generic software (xml browsers, xml or text editors, etc). VOTable is
>> viewable enough to qualify :-)
>> 
>> 
>> > to have the browser merely save the output to a file (or possibly
>> > display it in an application if the MIME type is configured), then
>> > the application MIME type would be preferred.
>> 
>> 
>> There's the catch: if you use text/xml;content=x-votable the claim in the
>> rfc is that mime dispatch will (should) ignore the parameter and dispatch 
>> to
>> the app responsible for text/xml, but if you use text/x-votable+xml then it
>> will dispatch to the app configured for that mimetype, and can dispatch to 
>> a
>> generic XML app if no specific one is known.
>> 
>> 
>> That's what it says anyway... If I look at the mime config of my browser,
>> there are quite afew examples under application/ which use +xml naming
>> convention, and a few under text, eg application/atom+xml,
>> application/rdf+xml, application/rss+xml, as well as things like
>> image/svg+xml.
>> 
>> 
>> 
>> 
>> > On Fri, 15 May 2009, Patrick Dowler wrote:
>> > > On Wednesday 29 April 2009 05:49:15 Mark Taylor wrote:
>> > > > Sec 2.7.1 and Sec 2.9:
>> > > >    The usual MIME type for VOTable is "application/x-votable+xml"
>> > > >    or maybe "text/x-votable+xml", not "text/xml; content=x-votable".
>> > > >    "content" is not listed in the text/xml MIME type registration
>> > > >    (RFC3023) as a mandatory or optional parameter of the text/xml
>> > > >    MIME type.  RFC3032 also explicitly considers and rejects the
>> > > >    idea of using a parameter like this to specify XML subformats -
>> > > >    see Appendix A.6.
>> > >
>> > > Which of "application/x-votable+xml" and "text/x-votable+xml" is
>> > > considered the best choice for TAP? For IVOA services in general? Are
>> > > there good reasons to chose one over the other?
>> 
>> 
>> 
>> --
>> 
>> 
>> Patrick Dowler
>> Tel/Tél: (250) 363-0044
>> Canadian Astronomy Data Centre
>> National Research Council Canada
>> 5071 West Saanich Road
>> Victoria, BC V9E 2M7
>> 
>> 
>> Centre canadien de donnees astronomiques
>> Conseil national de recherches Canada
>> 5071, chemin West Saanich
>> Victoria (C.-B.) V9E 2M7
>