MIME types in DAL services

[Doug Tody]

Hi Mark -

I actually did a test to check on this: I modified a test copy of my
DALServer code to return application/x-votable+xml, and then tried
the standard test query.  Both Firefox and IE fail to do anything
useful with the response, producing a popup instead.  If instead we
use "text/xml" or "text/xml;<anything>" then the browser will display
the response as pretty-printed XML.

I think this makes sense; basically what the MIME type is telling
the browser to do is direct the document to whatever application is
registered for this specific MIME type.  The "text/xml;<subtype>"
version reverses the priority, hence may be more appropriate for
cases where a generic display capability is desirable (such as for
the query response).  Use of a stylesheet is also possible with a
document identified to a browser as text/xml.

 	- Doug


On Mon, 23 Apr 2007, Mark Taylor wrote:

> On Mon, 16 Apr 2007, Doug Tody wrote:
>
>> For years now, the query response from cone search and SIAP services
>> has come back with a content type of "text/xml".   This is convenient,
>> as we can issue simple queries in a Web browser and view the results
>> directly, even though the document returned is actually a VOTable.
>> 
>> However, the current generally accepted MIME type for VOTable documents
>> appears to be "application/x-votable+xml".  This is probably the most
>> accurate and correct content specification, and is best in cases where
>> the document is expected to be passed off to some application which
>> understands the VOTable format.
>> 
>> Another approach which has been played with a bit is to use
>> MIME-type parameterization, e.g., "text/xml;subtype=votable" (the
>> form "text/xml;x-votable" has also been suggested but may not be
>> legal syntax).  The advantage of this approach is that the base type
>> remains "text/xml", and any standard XML tool, such as a browser. will
>
> Doug,
>
>> be able to do something useful with this content (if a browser sees
>> "application/x-votable+xml" it will in general have no clue what
>> to do and will prompt for what you want to do with the document).
>
> this isn't/shouldn't be true for well-written applications. As explained in 
> RFC3023 (section 7), the idea of the *+xml MIME convention is so that a 
> specific type (such as VOTable) which benefits from special handling can be 
> defined, but that applications which do not know about this specific type can 
> fall back to standard XML processing.  See Appendix A.6 of RFC3023
> for an argument against doing something along the lines of
> text/xml;subtype=votable (subtype is in any case not a standard
> parameter of application/xml).  Admittedly, I'm not sure how many
> applications actually do this +xml media type handling properly.
>
>> The question is what is the best approach for DAL services, most
>> notable in the case of VOTable (although parameterization is more
>> general).  My suggestion is that we use "application/x-votable+xml",
>> possibly with parameterization, as the FORMAT qualifier for datasets
>> returned by the service, and continue to use "text/xml", possibly
>> with parameterization, for the query response, for consistency with
>> existing services and so that we can continue to have the ability to
>> view simple queries directly in a browser.
>
> I would therefore argue that application/x-votable+xml for both
> query response and datasets is the correct thing to do.  However, if
> pragmatic considerations (e.g. most web browsers failing to do the
> right thing with it) dictate, I might be persuaded otherwise.
>
> Mark
>
> -- 
> Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
> m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/
>