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 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
  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
  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'
  this comment should be removed; VOTable is not a query mechanism.
• re 2: Data Model
  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
  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__
  refers to an 'above example' with an Epoch parameter: the example does not exist
• re 3: XML Schema
  the link to the schema should be an ivoa.net url
• re 3.1, last para: wrong PARAM
  the description refers to a 'PARAM parameter (the Epoch)': the actual param is Telescope
• re 3.3, COOSYS: values
  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?
  what is the difference between using COOSYS here or in the DEFINITIONS element?
• re 3.4: related tables
  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
  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
  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?
  what is the difference between href="glu://..." and gref="glu://..."? 'higher-level protocol' doesn't seem to be explained.
• re 3.5: content-role
  what is the parser supposed to do with this? what does it mean?
• re 3.6, para 2: father_
  this may be a translation problem: in English, one refers to the parent element, not _father
• re 3.6, last para: ref attribute
  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
  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
  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
  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
  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
  are the unit values enumerated under some schema? how are they validated?
• re 4.6: MIN/MAX & OPTION
  is it valid to have both MIN/MAX and OPTION? Schema allows both.
• re 4.7: order of GROUPed FIELDs
  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
  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
  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
  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
  what is the reader and where is it defined what the reader must do?
• re 5.1, last para: trailing blanks
  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
  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.

Follow-up of the discussion on the VOTable forum

• 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 my 9 June response to the RFC on the VOTable list.

-- RayPlante - 6 July 2004