VOTable v1.3: Request For Comments

This page contains public discussion of the VOTable v1.3 Proposed Recommendation. The RFC is announced on 29 March 2013 and will run until 29 April 2013.

Version under review

PR-VOTable-1.3-20130315 (for RFC),
PR-VOTable-1.3-20130430.pdf (for TCG review, incorporating RFC comments),
PR-VOTable-1.3-20130806.pdf (incoporating TCG comments)

RFC Review Period

29 March 2013 - 29 April 2013

TCG Review Period

30 April 2013 - 29 May 2013

Change Overview

Changes since the previous version 1.2 are mainly in the areas of representation of null values and serialization. A detailed list of the changes is available in section 9.2 of the document.

This version of the document has been developed within the public subversion repository Volute, in directory projects/votable, where the exact changes made to the LaTeX source and XML Schema can be seen.

Implementations and Validators

VOTable 1.3 has been implemented in the following software items:

• STIL 3.0-4/STILTS 2.5/TOPCAT 4.0b (set system property votable.version=1.3 in STILTS/TOPCAT for VOTable v1.3 output)
• The GAVO TAP service at http://dc.g-vo.org/tap
• Aladin beta 7.547 is now supporting VOTable 1.3 for reading (BINARY2 + LINK + note 1.2/2.0 "STC in VOTable")

A VOTable validator which validates all versions of VOTable including 1.3 is provided in the votlint command of STILTS v2.5.

-- MarkTaylor - 2013-03-28

---

---

In order to add a comment to the document, please edit this page and add your comment to the list below. When the author(s) of the document have considered the comment, they will provide a response after the comment.

Additional discussion about any of the comments or responses may be conducted on the votable@ivoa.net mailing list. However, please enter your initial comments here for full consideration in any future revisions of this document.

---

IVOA Community Comments during the RFC period (29 March 2013 - 26 April 2013)

(please add comments here)

---

TCG Comments during the RFC period (29 March 2013 - 26 April 2013)

(TCG members are encouraged to consider the document during the RFC stage so that any problems can be addressed before the TCG Review stage when the chair or vice chair of each WG will be required to review it).

Theory Interest Group

Comments by Franck on the 2nd April 2013

As mentionned during the discussions on the mailing list, it would be useful the document would be more precise on the way to include semantics concepts (as SKOS) in a VO-Table.

Mark suggested two solutions :

1) external communities (like Theory I.G.) could define their own conventions like content-role="skos"

2) use content-role="type"

Maybe solution 2 is better than solution 1 since somebody implementing VO-Table may not be aware of all the possibilities defined by each community.

So would it be possible to specify this in the documentation of VO-Table adding, in section 3.5, the sentence suggested by Mark during the discussions on the mailing list :

"This content-role value would for instance be appropriate to mark the LINK's href value as a SKOS concept."

Comments from NormanGray, 2013-04-04:

I agree that there is scope for external communities to define their own conventions, but I don't think there's a need for such an action here.

The language in the LINK section is intended to suggest that the content-role='type' URL suggests a type-like relationship, carefully avoiding any restriction to SKOS. This appears to create ambiguity, but doesn't really: any application which can make use of one of the values here (such as a 'type' which is a SKOS concept) will 'know' what values it can interpret, and therefore will certainly know what sort of thing (ie a SKOS concept) the value is. This implies (should it be made explicit?) that applications should ignore any types they do not recognise, and that VOTable authors should bear this in mind when writing the VOTable. Any application which wants to be generic here can retrieve the URL (presuming that the maintainers of that URL are following good practice and have made the URL dereferenceable) and that way discover what type of thing it is.

When drafting this section, Mark and I hoped to make this reasonably clear, but still concise. Clarifying edits would I'm sure be welcome.

It would also be useful (this is Franck's off-line suggestion) to have a brief example in the LINK section. Is the following too minimal?

<LINK content-role="type" href="http://purl.org/astronomy/vocab/PhysicalQuantities/Distance"/>

• I have added the suggested text and example in section 3.5 (volute revision 2139) -- MarkTaylor - 2013-04-26

Application Working Group

Comments by Pierre Fernique on the 11th April 2013

Page 14 - 4.7 VALUES Element
The example still used a ref="J2000" reference used in old COOSYS definition and in note 1.2 "STC in VOTable". But this possibility has been removed in the last note (2.0) and prefer to use FIELDref forward referencing method.
I suggest to remove it.

Pierre is absolutely right, both the ref and the utype in that example are spurious traces of Note 1.0 style metadata and should be removed (this is just a redactional change, since the example really is not about either of those, which is why the necessity for the change was not noticed in the first place). Looking for other suprious references in the text, I noticed the XMLDATA example on p. 32 also contains spurious occurrences of ref="J2000" which should be removed (even more so since the fragment doesn't contain a matching element. -- MarkusDemleitner - 2013-04-23

• both done (volute revision 2138) - thanks -- MarkTaylor - 2013-04-26

Comments from TCG members during the TCG Review Period: 30 Apr 2013 - 29 May 2013

WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard.

IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.

TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham)

Approved. -- SeverinGaudet - 2013-08-09

Applications Working Group ( _Mark Taylor, Pierre Fernique)

Approve. -- MarkTaylor - 2013-04-30

Data Access Layer Working Group ( Patrick Dowler, Mike Fitzpatrick)

On page 20, first bullet point about null values: the second sentence seems to have the opposite of the intended meaning. I think it should read "It is only possible..."

• No, it says what it's supposed to, but the wording is maybe bad. I'm trying to say that you can't mark the whole array as being null in this way ("cell" meaning cell of the table, not element of an array in that cell). Clarified by writing this sentence instead: "Although the magic value approach can mark individual elements of an array as null, it cannot mark the whole array as null". (volute revision 2243) -- MarkTaylor - 2013-07-22

Approved. -- PatrickDowler - 2013-05-30

Data Model Working Group ( _Jesus Salgado, Omar Laurino)

The document is clear and very well written. Approved.

A couple of comments:

Page 11: LINK description. content-role has two different values defined in the document (doc and type). Other possible values are claimed to be outside the scope of the VOTable specification but it is a little bit ambiguous where the possible values are defined. Should it be done by semantics working group? DM group? Is it more or less free?. A clarification in the text would be useful.

• I replaced the relevant text with this: "Other values of the content-role attribute may be defined as appropriate outside of this VOTable specification, for instance by the Semantics Working Group or as part of other standards that make use of VOTable." (volute revision 2238) -- MarkTaylor - 2013-07-19

Page 15: GROUP description starts with a historical view of this element. I would prefer a two lines definition in the first place. Something like "GROUP is an element used to associate PARAMs (directly or through PARAMrefs) and FIELDs (by using FIELDrefs)" (or similar)

• I rephrased the start of this section to avoid the historical emphasis (volute revision 2237). -- MarkTaylor - 2013-07-19

-- JesusSalgado - 2013-06-07

Grid & Web Services Working Group ( Andreas Wicenec, Andre Schaaff)

Approved

Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner)

7.1 vs. 7.2 Elements vs. Attributes, in section 7.1 the underline refers to expansion whereas in 7.2 the underline
mean a new addition to schema. Using the same markup for these in 2 different ways is a little confusin.
I was looking for any modified schema first, so this is subtle for how 1.3 varies.

• good call - I have removed the underlinings in sec 7.2 (volute revision 2239) - MarkTaylor - 2013-07-22

For 9.2 Why not combine the 3 in 4th bullet of reorder them so that the section is identified before the
change description

• reordered (volute revision 2240) - MarkTaylor - 2013-07-22

For the text added to encourage
STC metadata declaration, there really is little to no detail here for STC/s that is
basis of the ObsCore. Note 7 update woulc more explicitly include the recommended
DM use for type definitions (also see http://wiki.ivoa.net/twiki/bin/view/IVOA/DALBasicFootprintHere)

• Markus was responsible for this part of the document. He has this to say: "STC-S carries its own metadata and type information, and VOTable cannot do much for it in either field (much like as for the unit attribute of FIELD, which should be empty for STC-S columns, too). Basically, with an xtype of adql:REGION, VOTable's done, and everything else is up to the STC-S parser. The related question of how to let applications figure out columns containing footprints is, I believe, not within scope for VOTable itself."

-- Document Approved GretchenGreene - 2013-07-19

Semantics Working Group ( _Norman Gray, Mireille Louys)

The only part of this document in which the Semantics WG has a particular interest is the section on the LINK element. The Semantics WG approves this document as a whole.

This is the first time that I (Norman Gray) have read through the complete document for some years (as opposed to some close reading of the LINK section), and I include below a few sub-editing remarks; I have no idea whether the text I've commented on is new in this version, or has been around since v1.0. The PR editors should treat these remarks with all the levity they deserve.

• Norman, belated thanks for these items. The target of this revision was explicitly (as agreed in TCG) to tackle a small number of specific issues rather than as a general tidying up, which could have considerable scope. I'm interpreting this as a policy of leaving questionable text of historical vintage intact unless it's genuinely wrong or confusing, so I'm going to ignore some of your comments, though we'll keep them on file in case of a more thorough overhaul of the text some time in the future, but I address a few as per my notes below. -- MarkTaylor - 2013-07-22

The document has a rather wide text block, which makes it slightly harder to read then is necessary, and gives it unbalanced margins.

p5, "VOTable was designed...": This reads oddly – XML is very different from blocks of 80-char card images! Perhaps this would be clearer as something like "VOTable was designed to be close, in structure and goals, to the FITS Binary Table format"

p5, 'URL': Pedantically, URLs don't exist any more, only URIs, and the double slash in the syntax 'protocol://location' is only for hierarchical URIs (and not for example DOIs).

p6, Sect. 1.2: The expansion of 'XML' should be "Extensible Markup Language" (it's the 'E' that's capitalised, not the 'X', according to http://www.w3.org/TR/xml11. Also, XML elements are usually described as containing 'content' rather than 'payload'.

p6, Sect 1.3: "...the values of the attributes typed in "magenta"." The word 'magenta' is formatted in blue, as opposed to the near-magenta of the 'red'. If this is a complicated meta-syntactic joke (which I would applaud in general), it should perhaps be a little better signposted.

• Only true in the PDF. In the HTML version, the word 'magenta' is formatted in ... red. I've reworded it to say that attribute values are "coloured" (though I'll change that to "colored" if anybody can argue it's more consistent with the rest of the document) (volute revision 2241).

p7, "However, if the number of rows is known": it's not clear what happens if this number of rows is incorrect. Is the value of this attribute purely advisory, or is a document with an incorrect number here deemed 'invalid'?

• I think it's fairly clear that it's only valid to fill this value in with the correct number of rows.

p10, Sect 3.2: the XML spec doesn't exclude the colon from IDs (IDs must match the 'Name' production (5) of XML, which starts with NameStartChar, which includes colon). Also, the XML 'Name' production includes large numbers of Unicode characters, and unless 'letters' is read as including these characters (which are presumably of class 'letter') the VOTable text could be read as excluding these, and so excluding otherwise XML-valid documents. For example ID=":François" would be XML-valid; would it be VOTable-valid? (there's a c-cedilla in there, in case it doesn't survive the wiki formatting)

• I've replaced the term "letters" with "Unicode letters", and replaced the prohibition on colons with "The : (colon) is reserved for namespace use and should be avoided." (this follows what it says in my copy of XML in a Nutshell - if you think this is seriously misleading I can adjust) (volute revision 2242)

Time Domain Interest Group ( _Matthew Graham, John Swinbank)

Data Curation & Preservation Interest Group ( Alberto Accomazzi)

Knowledge Discovery in Databases Interest Group ( George Djorgovski)

Theory Interest Group ( _Franck Le Petit, Rick Wagner)

Concerns of the Theory I.G. about LINK have been taken into account.

We approve the proposal.

Standards and Processes Committee ( Francoise Genova)