[TAP] draft 0.42

[Francois Ochsenbein]

Hi Pat,

>
>On Monday 27 April 2009 07:04:51 Francois Ochsenbein wrote:
>>Sorry for the length of this message -- I tried nevetheless
>>to be as brief as > possible in the enclosed comments related
>>to TAP Version 0.42. Some comments are just typos, but a
>> couple imply VOTable adjustments:
>>
>> ==> the usage of the <INFO> tag (sec. 2.9): should we (I mean the
>>       VOTable group) give up with the addition of sub-elements
>>       like <DESCRIPTION> in <INFO>, which are included in VOTable1.2 ?
>
>This is in reference to placing content directly inside the INFO element 
>rather than using a child DESCRIPTION? If VOTable requires the child element 
>then the examples should be changed to comply. This section was not meant to 
>suggest a VOTable change, just how to use existing features. So, it should 
>have a child DESCRIPTION rather than child content?
>

===> Good, thanks !

>> ==> 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 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') ? 

Cheers, francois

=======================================================================
Francois Ochsenbein    ------   Observatoire Astronomique de Strasbourg
   11, rue de l'Universite 67000 STRASBOURG  Phone: +33-(0)390 24 24 29
Email: francois at astro.u-strasbg.fr (France)    Fax: +33-(0)390 24 24 17
=======================================================================