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.

Regarding the new placement of INFO elements (post-operational diagnostics) - I don't have any objection to this in principle, but is there a good reason to allow INFOs at the end of all the elements DATA, TABLE, RESOURCE and VOTABLE? Since an INFO can appear after a DATA, it seems unnecessary complication to allow it as the last element of DATA as well. It turns out that implementing this presents some difficulties in STIL. If there's good reason for it, I will work through them, but if there's no good reason for it I'd suggest to remove that possibility, so that the INFO can appear only at the end of TABLE, RESOURCE and VOTABLE.

There is also a small number of typos and minor items:

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

From NormanGray

MIME Types The document proposes using application/x-votable+xml for the VOTable MIME type: I don't believe this is appropriate for a standard that is intended to be taken seriously. RFC 4288, sect 3.4 says:

   These types are unregistered, experimental, and for use only with the active
   agreement of the parties exchanging them. [...] it should rarely, if ever, be
   necessary to use unregistered experimental types.  Therefore, use of
   both "x-" and "x." forms is discouraged.

utypes: There is not yet any utypes standard document; is it appropriate to refer to utypes in an IVOA standard before utypes are themselves standardised? (unless standardisation of the current pre-draft is regarded as a foregone conclusion)

Code generation: for what it's worth, I also agree with Mark's remarks above about adding gratuitous attributes in order to work around claimed deficiencies in code-generation software. (i) there still doesn't appear to have been any convincing demonstration that this is a real problem (so it's sounding like the 'XML parsers reorder elements' myth), and (ii) if code-generation software produces wrong outputs for correct inputs, then ... use different software.

-- NormanGray 2009 Sep 6

From PatrickDowler

xtype: While xtype is useful in services like TAP, the constants (STC-S and iso8601) are not that useful. One could use xtype="stc:Region" in place of STC-S and have the same meaning, with the additional clarity that stc:Region is a type while STC-S is a format (note: stc:Region has an implied STC-S format, but in services the allowed formats should be specified by the service; I am not sure if this is really the best choice from stc). Similarly, one could just use xtype="stc:ISOTime" directly. While the iso8601 xtype could be used in tap, the STC-S value does not distinguish between regions and points. In working on another problem, I came to the conclusion that point would be better handled by something like

xtype="stc:Position2D" datatype="double" arraysize="2" ref="the_coordsys"

and then the content is the usual comma-delimited pair of numeric values, and the ref connects the values to a common coordinate system. It is possible that the stc xtype(s) should have more extensive context that just the class names shown above... a detail.

Given that this can/should be done via STC (or other specifications that define datatypes), I think the pre-defined constants should be removed from the VOTable spec. They will just provide an additional choice and confusion for service implementors and application writers and STC already provides types for these two values.

-- PatrickDowler 2099/09/09

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)

Many expert eyes have gone over this document carefully, so I only focused on the changes between V1.1 and V1.2 that are noted in Section 8. These all seem in accord with the recent discussions.

Theory (Herve Wozniak, Claudio Gheller)

TCG (ChristopheArviset, Severin Gaudet)

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->