VOTableRFC < IVOA

---++ <nop>VOTable RFC

This document will act as *RFC* centre for the VOTable V1.1 Proposed Recommendation (__note:__ this document is not yet available from the IVOA Documents area, a link will be posted when it is).

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used here (and in ResourceMetadataRFC); include your TWiki.WikiName so authors can contact you for further information. When the author(s) of the document have considered the comment, they will provide a response (either after the comment or at the bottom of the document linked to from the comment).

Discussion about any of the comments or responses should be conducted on the VOTable mailing list, votable@ivoa.net.

---++ Comments

The following comments are all from TonyLinde:
   * re 1.1, para 2: VOTable as storage<br>VOTable should not be represented as a storage format. Its only purpose is as a data transfer format.
   * re 1.1, *Data Storage*, para 2: metadata storage<br>VOTable should not be represented as a way of storing metadata. The IVOA _Data Model_ effort will define the metadata that represents VO information and the format in which it will be represented. It should be made clear that the VOTable metadata representation method cannot be seen as a long term solution.
   * re 1.1, *Data Storage*, para 2: 'implicit query to a server'<br>this comment should be removed; VOTable is not a query mechanism.
   * re 2: *Data Model* <br>this section should begin with a note that the VOTable representation of a Data Model will be superseded by the work of the IVOA _Data Model_ group.
   * re 2, list of expressions: *Table* <br>the __Table__ entity is not used anywhere else in the list which would fit it into the VOTable definition: where does it belong?
   * re 2, para 3: __Epoch__<br>refers to an 'above example' with an Epoch parameter: the example does not exist
   * re 3: XML Schema<br>the link to the schema should be an ivoa.net url
   * re 3.1, last para: wrong PARAM<br>the description refers to a 'PARAM parameter (the Epoch)': the actual param is __Telescope__
   * re 3.3, *COOSYS*: values<br>how are the values of COOSYS set? Is it a fixed enumerated list? If so, where are the values to be found? Or can anything be put here?
   * re 3.4, *COOSYS*: why?<br>what is the difference between using COOSYS here or in the DEFINITIONS element?
   * re 3.4: related tables<br>in the comment, 'a RESOURCE is basically a set of related tables': related in what way? Ie, how should tables be related such they can be represented as a resource?
   * re 3.4: recursiveness<br>if RESOURCE can be 'recursive', what does this mean? Ie what type of data is being represented by a recursive resource? Would an example here help?
   * re 3.5: *LINK* <br>in what way are parsers expected to 'understand' the 'three common protocols'? What is the parser expected to do with the object at the end of the link? Eg, does it embed the data in the element being parsed, shell out to a browser etc?
   * re 3.5, gref: why?<br>what is the difference between href="glu://..." and gref="glu://..."? 'higher-level protocol' doesn't seem to be explained.
   * re 3.5: *content-role* <br>what is the parser supposed to do with this? what does it mean?
   * re 3.6, para 2: _father_<br>this may be a translation problem: in English, one refers to the __parent__ element, not _father_
   * re 3.6, last para: *ref* attribute<br>would it not be better to have a separate element, REFTABLE, with no FIELD & PARAM children so that user cannot put these in by mistake
   * re 3.6, last para: *ref* attribute<br>in fact, why not make such _abstract_ definitions part of the DEFINITIONS element, so that all referenced elements are in there
   * re 4.1: *datatype* attribute<br>this implies that the datatype attribute is not required when the ref attribute is present but the schema does not allow this
   * re 4.1: *ref* attribute<br>presumably this is a reference to another FIELD/PARAM element? (this is not stated) If so, where can the referenced FIELD/PARAM element exist - anywhere, at any level? Can a FIELD ref to a PARAM and vice versa?
   * re 4.1: *type* attribute<br>the text says this is not part of the standard yet it appears in the schema. This should be removed from both to avoid confusion or included.
   * re 4.3: *unit* <br>are the unit values enumerated under some schema? how are they validated?
   * re 4.6: MIN/MAX & OPTION<br>is it valid to have both MIN/MAX *and* OPTION? Schema allows both.
   * re 4.7: order of GROUPed FIELDs<br> if FIELDs are contained in a GROUP, how does this resolve in the order of TD elements in the TABLEDATA element? Or must the TDs be grouped in the same way?
   * re 4.7, second example: *ref* <br>do referenced FIELDs have associated TD columns in the TABLEDATA? What are these example FIELDs referencing, given that the ref values are the same as the FIELD elements they are replacing. I think this example is somewhat confusing.
   * re 4.7, third example: order of FIELD/PARAMs<br>is there any meaning to the order of FIELD and PARAM elements apart from the order of the TD elements? eg, when parsed are the PARAM values returned as if they were embedded in the TDs in the order that the PARAM elements are embedded within the FIELDs?
   * re 5, first para: *ref* FIELDs<br>what does a reference to a *"true" column* mean? Section 4 does not explain this; there is nothing anywhere else in the document about true columns.
   * re 5.1, para 4 (immediately after diagram): *reader* <br>what is the _reader_ and where is it defined what the reader must do? 
   * re 5.1, last para: *trailing blanks* <br>this also refers to how the data is read (parsed?). If parsing instructions are to be part of the spec they should be highlighted more prominently - given a separate section perhaps.
   * re Appendix A: extensions<br>I don't think _possible_ extensions are a valid part of the specification; they should be contained in a separate IVOA *Note* document and only referenced in this document as a warning to users of the spec that some part may be changed in the future.

------------------------

*%RED% Follow-up of the discussion %ENDCOLOR%* on the [[http://www.ivoa.net/forum/votable/][VOTable forum]]

   * [[http://www.ivoa.net/forum/votable/0404/0602.htm][Answer by FrancoisOchsenbein]]

   * followed by several other messages with Subject
         _Comments on V1.1 - Future of VOTable (flame bait sigh)_

------------------------

   * I posted 3 critical concerns in [[http://www.ivoa.net/forum/votable/0406/0686.htm][my 9 June response]] to the RFC on the VOTable list.  

-- RayPlante - 6 July 2004
This topic: IVOA > WebHome > IvoaVOTable > VOTableRFC
Topic revision: r4 - 2004-07-06 - RayPlante