VOTable1.2: Request for Comments

This document will act as RFC centre for the VOTable-1.2 Proposed Recommendation.

Review period: 2009 July 10 – 2009 August 21 2009 Sep. 9 (09/09/09)

In order to add a comment to the document, please edit this page and add your comment to the list below (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 after the comment.

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

Comments from the community

• Sample comment by WikiName
  • Response (by WikiName)

From MarkTaylor

• As I and others have argued elsewhere (http://www.ivoa.net/forum/votable/0903/date.htm) the changes to the INFO element may cause backward compatibility issues. These issues are probably not too serious, but may cause annoyance, and I'm not convinced that justification for the change has been demonstrated.
• As I have argued elsewhere (http://www.ivoa.net/forum/votable/0907/date.htm) I do not believe that the introduction of the spurious "encoding" attribute on the TD element is justified.

A related item which I've only noticed more recently, in the course of implementation is:

• The new "ID" attribute on the TR element has apparently been introduced for the same reasons as the TD "encoding" attribute, and I'm against it for the same reasons. However, it is even more problematic, since correctly processing an xs:ID-type attribute is expensive because of the need to maintain crossreferences (I can explain in detail on request). There would be major impacts on STIL's efficiency in VOTable streaming if it took this ID attribute seriously.

There are two other changes from VOTable 1.1 which I have queried in earlier drafts (http://www.ivoa.net/forum/votable/0903/0999.htm) and which have not been addressed or discussed further:

• The TABLE element now permits multiple DATA elements. I can't see this is a good idea - I presume it's a mistake in the schema. Should be corrected.
• The VOTABLE and RESOURCE elements now permit a GROUP to appear as a direct child. This is probably reasonable in order to group PARAMs which are already permitted there, but this change should be documented in section 8.

Section 8 "Differences between 1.1 and 1.2" is useful but unfortunately incomplete. The changes since v1.1 of the VOTable Recommendation that I've spotted which are not documented here are (as elaborated on above):

1. New "encoding" attribute on TD element
2. New "ID" attribute on TR element
3. TABLE element permits multiple DATA children
4. GROUP element permitted as direct child of VOTABLE and RESOURCE

At least the first three of these I'd like to see changed, as noted above. However, if they are not, they should be recorded in section 8, preferably with reasons. Otherwise, the only way that VOTable authors and implementors, and reviewers of the document, are likely to spot them is by very close reading of the schema text itself, which is hard work.

• Section 3: "Each Resource element contains one or more TABLE elements" - should be "... zero or more ...".
• Section 4.1: "elment" should be "element".
• Section 4.3: "expresses a spatial of temporal coordinate" should be "... spatial or temporal ...".
• Section 4.7: The new paragraph beginning "section 6 indicates ...": I don't believe that a null scalar "char" value can be represented with an empty TD element. Also, use in this paragraph of the phrase "default null value" seems a bit confusing to me; I suggest instead the phrase "representation of the null value" or "null representation".
• Section 5.2: The example here contains a PARAM element with text content; this is not permitted.

-- AlbertoMicol - 04 Sep 2009

I fully support Mark's comment on the INFO backward compatibility issues. It is an unnecessary burden for many of us, without a clear immediate advantage (as I understood it, it is only done to allow future extensibility). Especially important given that SIA 1.0 and SSA 1.04 relies on the INFO tag to provide QUERY_STATUS information and SERVICE_PROTOCOL versions; examples quoted from PR-SIA-1.0-20090521 and SSA-20080201 (REC):

<INFO name="QUERY_STATUS" value="OK">  Successful Search</INFO>
<INFO name="QUERY_STATUS" value="ERROR">DEC out of range: DEC=91</INFO> 
<INFO name="SERVICE_PROTOCOL" value="1.02">SSAP</INFO>

From MarkusDemleitner

First off, +1 from me on the "first three issues" comment by Mark. But I have another one: I'm unhappy about the inclusion of the sample document with embedded STC in 3.1. In effect, it raises that note to a recommendation status, and I think it's too early for that since there's been very little discussion about it. So, I'd like to propose that the sample document is removed.

Background: The note has some issues I've sent to Francois, but mainly I think it's wrong to clobber the column's utype attributes for something so common -- it would mean that specific data models could not assign utypes of their own to columns carrying STC information (or clients would have to know all these data models to know what STC roles are behind these specific utypes). Also, libraries have a much easier time if STC info remains confined to one element rather than it being all over the VOTable. So, my suggestion was to reference the the columns from the AstroCoords group rather than the other way round, something like

<GROUP utype="stc:AstroCoords.Position2D.Value2.C1" ref="RA1"/>

But well, that's something to be discussed elsewhere. I just think we shouldn't promote the note to de-facto recommendation just yet.

Comments from the TCG during the normal RFC period (2009 July 10 -- 2009 August 21 September 09)

Applications (Tom McGlynn, Mark Taylor)

Data Access Layer (Keith Noddle, Jesus Salgado)

Data Model (Mireille Louys, AnitaRichards)

Grid&Web Sevices (Matthew Graham, Paul Harrison)

Registry (Ray Plante, Aurelien Stebe)

Semantics (Sebastien Derriere, Norman Gray)

VOEvent (Rob Seaman, Alasdair Allan)

VO Query Language (Pedro Osuna, Yuji Shirasaki)

VOTable (Francois Ochsenbein)

Standard and Processes (Francoise Genova)

Astro RG (Masatoshi Ohishi)

Data Curation & Preservation (Bob Hanisch)

Theory (Herve Wozniak, Claudio Gheller)

TCG (ChristopheArviset, Severin Gaudet)

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->