International Virtual Observatory Alliance

Difference: RfcPage (6 vs. 7)

Revision 72009-09-04 - AlbertoMicol

META TOPICPARENT	name="IvoaVOTable"

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

I will flag up here a couple of issues that I've noted in earlier drafts of this document. Francois and I disagree on them; I will concede if other reviewers of the document don't regard them as problematic.

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. The same applies to the "ID" attribute on the TR element, which is apparently present for the same reasons.
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.

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):

New "encoding" attribute on TD element
New "ID" attribute on TR element
TABLE element permits multiple DATA children
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.

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.

Added:

>
>

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

Hence, those protocols should be ammended, and all existing SIAP and SSAP services would need an upgrade, unless IVOA accept and handle multiple versions of those protocols requiring different votable versions (quite an unnecessary complication and a burden for applications developers).

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

View topic | History: r45 < r44 < r43 < r42 | More topic actions...