[TAP] draft 0.42

[Mark Taylor]

On Tue, 28 Apr 2009, Francois Ochsenbein wrote:

> >> ==> the 'format' as a new attribute of <FIELD> (and therefore
> >>       of <PARAMETER>): I assume this word is replaced by 'encoding',
> >>       with a similar meaning of what is proposed in Apx A.5 of
> >>       VOTable1.2. Is that agreeable ?
> >
> >I was thinking some more about format vs encoding... The encoding as used in 
> >A.5 is a way to encode binary as text and does not specify the format (of the 
> >actual value). For example, one would would normally describe a graphic file 
> >with (not specifically VOTable here):
> >
> >encoding="base64" format="image/png"
> >
> >So, despite my own suggestion, I think format and encoding should remain 
> >distinct (also consistent use of the terms in http: content-type aka format 
> >and content-encoding). 
> >
> >The use/meaning of encoding in A.5 could remain unchanged, although it would 
> >be nice to be able to put it once in the FIELD rather than in every TD.  I 
> >would go back to Mark's original suggestion of a format attribute (for FIELD 
> >and PARAM), which TAP would use like this, for example:
> >
> ><FIELD datatype="char" arraysize="*" format="STC-S" />
> >
> >to describe a region column, or 
> >
> ><FIELD datatype="char" arraysize="*" format="ISO8601" />
> >
> >to describe a timestamp column. One could in principle store a graphic file in 
> >a BLOB or varbinary column and describe it as:
> >
> ><FIELD datatype="unisgnedByte" arraysize="*" 
> >  encoding="base64" format="image/png" />
> >
> >assuming the proposal in A.5 is also adopted and encoding is allowed in the 
> >FIELD and not just the TD.
> 
> ===> Yes, I think you are right, the meanings are different.
> 
>      In fact, up to now we always carefully avoided to place
>      in the metadata description (essentially made of FIELDs)
>      details which would apply to one of the serialisations:
>      for instance if we introduce the 'encoding' as a FIELD
>      attribute, and set it to 'base64', it would mean that
>      all serialisations (including the BINARY) would then
>      contain a base64-encoded representation of the data;
>      the FIELD data-type should then be 'char' and not
>      'unsignedByte'.

I do *not* think there is any call for adoption of an encoding type in
the sense of appendix A.5, partly for the reason Francois quotes 
above about serialization-dependent issues.  The suggestion I've 
made has been only about describing the meaning of data stored in
a column, not about how it is serialized into a VOTable.  I tried to
make this clear in an earlier message:

On Tue, 21 Apr 2009, Mark Taylor wrote:

> On Mon, 20 Apr 2009, Patrick Dowler wrote:
>
> > Alternatively, the VOTable 1.2, Appendix A lists some possible/considered
> > extensions. A.5 has encoding per table data cell, eg
> >
> > <TD encoding="base64"> .... </TD>
> >
> > I am not sure if VOTable or services are to specify the allowed encodings an
d 
> > their names... hopefully the service as this extensible and adaptable.
> >
> > I think what Mark and I are talking about is very close to this, except that
 
> > one can specify it in the FIELD instead of each TD. It also extends the
>
> this is not what I have in mind.  The TD encoding proposal (not adopted)
> that you mention is about how (usually numeric array) data is stored
> in the XML stream.  It is TABLEDATA specific, and provides information
> directed at VOTable parsing software, not at applications trying to
> understand the content of cells.  A good VOTable parser would make
> it transparent to applications whether the proposed TD encoding
> attribute had been used or not, in the same way that applications
> should not need to know or care whether a VOTable uses the TABLEDATA,
> BINARY or FITS encoding.  My proposal in contrast is all about
> information directed to applications.

Concerning the name of the new attribute that I am proposing:

On Tue, 28 Apr 2009, Francois Ochsenbein wrote:

>      I just don't like the 'format' name for this new attribute,
>      it means something completely different from the 'format' used
>      in the FITS vocabulary (VOTable is expected to stay compatible
>      with FITS format). Could it be 'mime' or 'content', or maybe
>      'ctype' (an analogy with 'utype') ? 

I don't think that "mime" is a good choice, as we don't want to restrict
it to MIME types, although a MIME type could certainly be a sensible
value of such a parameter.  "encoding" makes some sense, but it's clearly
causing confusion.  However "ctype", "content" or "content-type" 
sound like good suggestions.

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/