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

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


-- RayPlante - 6 July 2004

Topic revision: r4 - 2004-07-06 - RayPlante
 
This site is powered by the TWiki collaboration platformCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback