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.
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.
