Mark,
yes, your syntax is much better.
A wiki page disscussing the MIME type agreed so far would be useful to me.
Guy
On Wed, 7 Sep 2005, Mark Taylor wrote:
> On Wed, 7 Sep 2005, Guy Rixon wrote:
>
> > Hi,
> >
> > my understanding is that most VOTable libraries still only support TABLEDATA
> > encoding of the table and not FITS or BINARY. Therefore, it's not robust to
> > send, e.g., a VOTABLE/BINARY document to an arbitrary comsumer. Can anybody
> > comment on this?
>
> Guy,
>
> The following VOTable parsers support all three defined VOTable encodings
> (TABLEDATA, BINARY, and FITS):
>
> - STIL
> (see http://www.starlink.ac.uk/stil/)
>
> - VO-India's C++ Streaming and non-streaming parsers for VOTable v2.0
> (see http://vo.iucaa.ernet.in/~voi/cplusparser_stream.htm)
> The web page for the non-streaming one says that it only
> does TABLEDATA, but this appears to be in contradiction with
> the change log - I haven't tested either.
>
> As far as I know, all other existing VOTable parsers support only
> TABLEDATA encoding. So your comment is correct.
>
> > If we have to be careful about which encodings we sent to which consumers,
> > then it may be necessary to distinguish the encodings in the MIME type. E.g.,
> > we might need application/xml+votable-tabledata and
> > application/xml+votable-binary. Comments?
>
> The general idea sounds reasonable. Detailed comments:
>
> 1. The agreed basic MIME type for VOTables is
> "application/x-votable+xml"
>
>
> 2. Rather than different MIME types for each encoding, this looks
> to me like a job for a subtype-specific parameter, presumably
> with a name such as 'encoding'. So your Content-Type would be
> one of
>
> application/x-votable+xml
> application/x-votable+xml; encoding=TABLEDATA
> application/x-votable+xml; encoding=BINARY
> application/x-votable+xml; encoding=FITS
>
> I would suggest that the parameter should be optional.
> The unqualified version (without an encoding parameter specified)
> would serve for the case where the software has been written
> prior to this suggestion, or the provider doesn't know the
> encoding, or the consumer doesn't care, or the document
> contains DATA elements with a mixture of different
> encodings(!). Alternatives are possible, e.g. to allow
> encoding=ANY which might cover some of the above cases while
> the unspecified value is permitted for backward compatibility.
>
> RFC2045 allows the parameter values to be case-sensitive;
> I suggest that we say it's not in this case.
>
> The parameter mechanism is used fairly widely in MIME media
> types; for instance the charset parameter of the text type
> (as in "text/plain; charset=iso-8859-1").
>
> See RFC 2045 and 2046, especially section 5 of RFC 2045 for
> discussion of media type/subtype parameters.
>
>
> A general comment: the existing agreement on the VOTable MIME type
> is not very prominently available anywhere (you have to dredge through
> the wiki to find
> http://www.ivoa.net/twiki/bin/view/IVOA/InterOpMay2005VOTable#Various_points
> and http://www.ivoa.net/forum/votable/0311/0380.htm).
> It would be good if it was more prominent, along with any changes
> such as the above which we decide to make.
> The VOTable specification document would be the obvious place to put it,
> but it may not be worth issuing a new version just to include that.
> Should I write up a wiki page detailing the currently agreed status
> or something?
>
> Mark
>
> --
> Mark Taylor Astronomical Programmer Physics, Bristol University, UK
> m.b.taylor@bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/
>
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 2005-09-08Z11:26:17