Difference: VOTableRfcV13 (1 vs. 21)

Revision 212013-08-19 - GretchenGreene

 
META TOPICPARENT name="WebPreferences"
Changed:
<
<

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.

Changed:
<
<
Version under review
PR-VOTable-1.3-20130315 (for RFC),
>
>
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)
Deleted:
<
<
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

Changed:
<
<
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.
>
>
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
Deleted:
<
<
 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
Deleted:
<
<
 -- JesusSalgado - 2013-06-07

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

Approved

Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner)

Changed:
<
<
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.
>
>
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
Changed:
<
<
For 9.2 Why not combine the 3 in 4th bullet of reorder them so that the section is identified before the
change description
>
>
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)
Changed:
<
<
  • 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."
>
>
  • 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."
Added:
>
>
-- Document Approved GretchenGreene - 2013-07-19
 
Deleted:
<
<
-- 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.

Changed:
<
<
  • 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
>
>
  • 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
Deleted:
<
<
 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.

Changed:
<
<
  • 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).
>
>
  • 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).
Deleted:
<
<
 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.
Deleted:
<
<
 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)
Deleted:
<
<
 

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)

META FILEATTACHMENT attachment="PR-VOTable-1.3-20130430.pdf" attr="" comment="VOTable PR version addressing RFC comments" date="1369916953" name="PR-VOTable-1.3-20130430.pdf" path="PR-VOTable-1.3-20130430.pdf" size="478400" user="MarkTaylor" version="1"
META FILEATTACHMENT attachment="PR-VOTable-1.3-20130806.pdf" attr="" comment="VOTable PR version addressing TCG comments" date="1375804190" name="PR-VOTable-1.3-20130806.pdf" path="PR-VOTable-1.3-20130806.pdf" size="754900" user="MarkTaylor" version="1"

Revision 202013-08-09 - SeverinGaudet

 
META TOPICPARENT name="WebPreferences"

<--  
-->

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)

Added:
>
>
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."

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

META FILEATTACHMENT attachment="PR-VOTable-1.3-20130430.pdf" attr="" comment="VOTable PR version addressing RFC comments" date="1369916953" name="PR-VOTable-1.3-20130430.pdf" path="PR-VOTable-1.3-20130430.pdf" size="478400" user="MarkTaylor" version="1"
META FILEATTACHMENT attachment="PR-VOTable-1.3-20130806.pdf" attr="" comment="VOTable PR version addressing TCG comments" date="1375804190" name="PR-VOTable-1.3-20130806.pdf" path="PR-VOTable-1.3-20130806.pdf" size="754900" user="MarkTaylor" version="1"

Revision 192013-08-06 - MarkTaylor

 
META TOPICPARENT name="WebPreferences"

<--  
-->

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.

Changed:
<
<
Version under review
PR-VOTable-1.3-20130315 (for RFC), PR-VOTable-1.3-20130430.pdf (for TCG review, incorporating RFC comments)
>
>
Version under review
PR-VOTable-1.3-20130315 (for RFC),
Added:
>
>
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)

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

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

META FILEATTACHMENT attachment="PR-VOTable-1.3-20130430.pdf" attr="" comment="VOTable PR version addressing RFC comments" date="1369916953" name="PR-VOTable-1.3-20130430.pdf" path="PR-VOTable-1.3-20130430.pdf" size="478400" user="MarkTaylor" version="1"
Added:
>
>
META FILEATTACHMENT attachment="PR-VOTable-1.3-20130806.pdf" attr="" comment="VOTable PR version addressing TCG comments" date="1375804190" name="PR-VOTable-1.3-20130806.pdf" path="PR-VOTable-1.3-20130806.pdf" size="754900" user="MarkTaylor" version="1"
 

Revision 182013-07-22 - MarkTaylor

 
META TOPICPARENT name="WebPreferences"

<--  
-->

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

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

Changed:
<
<
  • 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). How about 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". ? -- MarkTaylor - 2013-05-31
>
>
  • 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.

Changed:
<
<
* 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 * 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)
>
>
  • 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
Deleted:
<
<
 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)

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

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

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)
>
>
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.
Added:
>
>
  • 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."
  -- GretchenGreene - 2013-07-19
Added:
>
>
 

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.

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

Added:
>
>
  • 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'?
Added:
>
>
  • 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)
Added:
>
>
  • 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)
 
Added:
>
>
 

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)

META FILEATTACHMENT attachment="PR-VOTable-1.3-20130430.pdf" attr="" comment="VOTable PR version addressing RFC comments" date="1369916953" name="PR-VOTable-1.3-20130430.pdf" path="PR-VOTable-1.3-20130430.pdf" size="478400" user="MarkTaylor" version="1"

Revision 172013-07-19 - GretchenGreene

 
META TOPICPARENT name="WebPreferences"

<--  
-->

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

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). How about 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". ? -- MarkTaylor - 2013-05-31
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.

Changed:
<
<
  • 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
>
>
* 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 * 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)
Added:
>
>
 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)

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

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

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)

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

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.

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

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)

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)

META FILEATTACHMENT attachment="PR-VOTable-1.3-20130430.pdf" attr="" comment="VOTable PR version addressing RFC comments" date="1369916953" name="PR-VOTable-1.3-20130430.pdf" path="PR-VOTable-1.3-20130430.pdf" size="478400" user="MarkTaylor" version="1"

Revision 162013-07-19 - MarkTaylor

 
META TOPICPARENT name="WebPreferences"

<--  
-->

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

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). How about 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". ? -- MarkTaylor - 2013-05-31
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.

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

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.

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.

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

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)

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)

META FILEATTACHMENT attachment="PR-VOTable-1.3-20130430.pdf" attr="" comment="VOTable PR version addressing RFC comments" date="1369916953" name="PR-VOTable-1.3-20130430.pdf" path="PR-VOTable-1.3-20130430.pdf" size="478400" user="MarkTaylor" version="1"

Revision 152013-07-05 - AndreSchaaff

 
META TOPICPARENT name="WebPreferences"

<--  
-->

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

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). How about 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". ? -- MarkTaylor - 2013-05-31
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.

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)

-- JesusSalgado - 2013-06-07

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

Added:
>
>
Approved
 

Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner)

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.

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.

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

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)

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)

META FILEATTACHMENT attachment="PR-VOTable-1.3-20130430.pdf" attr="" comment="VOTable PR version addressing RFC comments" date="1369916953" name="PR-VOTable-1.3-20130430.pdf" path="PR-VOTable-1.3-20130430.pdf" size="478400" user="MarkTaylor" version="1"

Revision 142013-06-11 - FranckLePetit

 
META TOPICPARENT name="WebPreferences"

<--  
-->

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

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). How about 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". ? -- MarkTaylor - 2013-05-31
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.

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)

-- JesusSalgado - 2013-06-07

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

Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner)

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.

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.

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

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)

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)

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

We approve the proposal.

 

Standards and Processes Committee ( Francoise Genova)

META FILEATTACHMENT attachment="PR-VOTable-1.3-20130430.pdf" attr="" comment="VOTable PR version addressing RFC comments" date="1369916953" name="PR-VOTable-1.3-20130430.pdf" path="PR-VOTable-1.3-20130430.pdf" size="478400" user="MarkTaylor" version="1"

Revision 132013-06-07 - JesusSalgado

 
META TOPICPARENT name="WebPreferences"

<--  
-->

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

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

Changed:
<
<
  • 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). How about 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". ? -- MarkTaylor - 2013-05-31
>
>
  • 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). How about 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". ? -- MarkTaylor - 2013-05-31
Deleted:
<
<
 Approved. -- PatrickDowler - 2013-05-30

Data Model Working Group ( _Jesus Salgado, Omar Laurino)

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

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)

-- JesusSalgado - 2013-06-07

 

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

Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner)

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.

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.

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

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)

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)

Standards and Processes Committee ( Francoise Genova)

META FILEATTACHMENT attachment="PR-VOTable-1.3-20130430.pdf" attr="" comment="VOTable PR version addressing RFC comments" date="1369916953" name="PR-VOTable-1.3-20130430.pdf" path="PR-VOTable-1.3-20130430.pdf" size="478400" user="MarkTaylor" version="1"

Revision 122013-05-31 - MarkTaylor

 
META TOPICPARENT name="WebPreferences"

<--  
-->

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

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

Added:
>
>
  • 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). How about 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". ? -- MarkTaylor - 2013-05-31
  Approved. -- PatrickDowler - 2013-05-30

Data Model Working Group ( _Jesus Salgado, Omar Laurino)

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

Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner)

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.

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.

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

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)

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)

Standards and Processes Committee ( Francoise Genova)

META FILEATTACHMENT attachment="PR-VOTable-1.3-20130430.pdf" attr="" comment="VOTable PR version addressing RFC comments" date="1369916953" name="PR-VOTable-1.3-20130430.pdf" path="PR-VOTable-1.3-20130430.pdf" size="478400" user="MarkTaylor" version="1"

Revision 112013-05-30 - PatrickDowler

 
META TOPICPARENT name="WebPreferences"

<--  
-->

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.

Changed:
<
<
Version under review
PR-VOTable-1.3-20130315 (for RFC), PR-VOTable-1.3-20130430.pdf (for TCG review, incorporating RFC comments)
>
>
Version under review
PR-VOTable-1.3-20130315 (for RFC), PR-VOTable-1.3-20130430.pdf (for TCG review, incorporating RFC 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
Deleted:
<
<
 

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.

Changed:
<
<

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

>
>

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

 
Changed:
<
<

Applications Working Group (Mark Taylor, Pierre Fernique)

>
>

Applications Working Group ( _Mark Taylor, Pierre Fernique)

Deleted:
<
<
Approve. -- MarkTaylor - 2013-04-30
 
Changed:
<
<

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

>
>
Approve. -- MarkTaylor - 2013-04-30
 
Changed:
<
<

Data Model Working Group (Jesus Salgado, Omar Laurino)

>
>

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

 
Changed:
<
<

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

>
>
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..."
 
Changed:
<
<

Registry Working Group (Gretchen Greene, Pierre Le Sidaner)

>
>
Approved. -- PatrickDowler - 2013-05-30
Added:
>
>

Data Model Working Group ( _Jesus Salgado, Omar Laurino)

 
Changed:
<
<

Semantics Working Group (Norman Gray, Mireille Louys)

>
>

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

 
Changed:
<
<
The only part of this document in which the Semantics WG has a particular
>
>

Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner)

Deleted:
<
<
interest is the section on the LINK element. The Semantics WG approves this document as a whole.
 
Changed:
<
<
This is the first time that I (Norman Gray) have read through the complete
>
>

Semantics Working Group ( _Norman Gray, Mireille Louys)

Deleted:
<
<
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.
 
Changed:
<
<
The document has a rather wide text block, which makes it slightly harder to
>
>
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.
Deleted:
<
<
read then is necessary, and gives it unbalanced margins.
 
Changed:
<
<
p5, "VOTable was designed...": This reads oddly – XML is very different from blocks of 80-char card
>
>
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.
Deleted:
<
<
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"
 
Changed:
<
<
p5, 'URL': Pedantically, URLs don't exist any more, only URIs, and the double
>
>
The document has a rather wide text block, which makes it slightly harder to read then is necessary, and gives it unbalanced margins.
Deleted:
<
<
slash in the syntax 'protocol://location' is only for hierarchical URIs (and not for example DOIs).
 
Changed:
<
<
p6, Sect. 1.2: The expansion of 'XML' should be "Extensible Markup Language"
>
>
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"
Deleted:
<
<
(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'.
 
Changed:
<
<
p6, Sect 1.3: "...the values of the attributes typed in "magenta"." The
>
>
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).
Deleted:
<
<
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.
 
Changed:
<
<
p7, "However, if the number of rows is known": it's not clear what happens if
>
>
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'.
Deleted:
<
<
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'?
 
Changed:
<
<
p10, Sect 3.2: the XML spec doesn't exclude the colon from IDs (IDs must
>
>
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.
Deleted:
<
<
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)
 
Changed:
<
<

Time Domain Interest Group (Matthew Graham, John Swinbank)

>
>
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'?
 
Changed:
<
<

Data Curation & Preservation Interest Group (Alberto Accomazzi)

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

Knowledge Discovery in Databases Interest Group (George Djorgovski)

>
>

Time Domain Interest Group ( _Matthew Graham, John Swinbank)

 
Changed:
<
<

Theory Interest Group (Franck Le Petit, Rick Wagner)

>
>

Data Curation & Preservation Interest Group ( Alberto Accomazzi)

 
Changed:
<
<

Standards and Processes Committee (Francoise Genova)

>
>

Knowledge Discovery in Databases Interest Group ( George Djorgovski)

Added:
>
>

Theory Interest Group ( _Franck Le Petit, Rick Wagner)

Standards and Processes Committee ( Francoise Genova)

 
META FILEATTACHMENT attachment="PR-VOTable-1.3-20130430.pdf" attr="" comment="VOTable PR version addressing RFC comments" date="1369916953" name="PR-VOTable-1.3-20130430.pdf" path="PR-VOTable-1.3-20130430.pdf" size="478400" user="MarkTaylor" version="1"

Revision 102013-05-30 - MarkTaylor

 
META TOPICPARENT name="WebPreferences"

<--  
-->

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.

Changed:
<
<
Version under review
PR-VOTable-1.3-20130315
>
>
Version under review
PR-VOTable-1.3-20130315 (for RFC), PR-VOTable-1.3-20130430.pdf (for TCG review, incorporating RFC 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)

Applications Working Group (Mark Taylor, Pierre Fernique)

Approve. -- MarkTaylor - 2013-04-30

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

Data Model Working Group (Jesus Salgado, Omar Laurino)

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

Registry Working Group (Gretchen Greene, Pierre Le Sidaner)

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.

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.

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

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)

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)

Standards and Processes Committee (Francoise Genova)

Added:
>
>
META FILEATTACHMENT attachment="PR-VOTable-1.3-20130430.pdf" attr="" comment="VOTable PR version addressing RFC comments" date="1369916953" name="PR-VOTable-1.3-20130430.pdf" path="PR-VOTable-1.3-20130430.pdf" size="478400" user="MarkTaylor" version="1"
 

Revision 92013-05-11 - NormanGray

 
META TOPICPARENT name="WebPreferences"

<--  
-->

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

Applications Working Group (Mark Taylor, Pierre Fernique)

Approve. -- MarkTaylor - 2013-04-30

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

Data Model Working Group (Jesus Salgado, Omar Laurino)

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

Registry Working Group (Gretchen Greene, Pierre Le Sidaner)

Semantics Working Group (Norman Gray, Mireille Louys)

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

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.

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

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)

 

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)

Standards and Processes Committee (Francoise Genova)

Revision 82013-04-30 - MarkTaylor

 
META TOPICPARENT name="WebPreferences"

<--  
-->

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
RFC Review Period
29 March 2013 - 29 April 2013
Added:
>
>
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)


Changed:
<
<

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

>
>

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

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)

Applications Working Group (Mark Taylor, Pierre Fernique)

Approve. -- MarkTaylor - 2013-04-30

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

Data Model Working Group (Jesus Salgado, Omar Laurino)

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

Registry Working Group (Gretchen Greene, Pierre Le Sidaner)

Semantics Working Group (Norman Gray, Mireille Louys)

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)

Standards and Processes Committee (Francoise Genova)

 

Revision 72013-04-26 - MarkTaylor

 
META TOPICPARENT name="WebPreferences"

<--  
-->

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
RFC Review Period
29 March 2013 - 29 April 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 Match 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).

Changed:
<
<

* Theory Interest Group

>
>

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"/>
Changed:
<
<

* Application Working Group

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

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

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

Revision 62013-04-23 - MarkusDemleitner

 
META TOPICPARENT name="WebPreferences"

<--  
-->

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
RFC Review Period
29 March 2013 - 29 April 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 Match 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"/>
Added:
>
>
 

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

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

Revision 52013-04-11 - PierreFernique

 
META TOPICPARENT name="WebPreferences"

<--  
-->

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
RFC Review Period
29 March 2013 - 29 April 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 Match 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:

Changed:
<
<
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.
>
>
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.
 
Changed:
<
<
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.
>
>
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"/>
Added:
>
>

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

 

Revision 42013-04-10 - MarkTaylor

 
META TOPICPARENT name="WebPreferences"

<--  
-->

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
RFC Review Period
29 March 2013 - 29 April 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:

Changed:
<
<
>
>
  • 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)
 
Changed:
<
<
>
>
  • 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 Match 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"/>

Revision 32013-04-04 - NormanGray

 
META TOPICPARENT name="WebPreferences"

<--  
-->

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
RFC Review Period
29 March 2013 - 29 April 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:

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

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

>
>
Comments from NormanGray, 2013-04-04:
Added:
>
>
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"/>
 

Revision 22013-04-02 - FranckLePetit

 
META TOPICPARENT name="WebPreferences"

<--  
-->

VOTable v1.3: Request For Comments

Changed:
<
<
This page contains public discussion of the VOTable v1.3 Proposed Recommendation.
>
>
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.
Deleted:
<
<
The RFC is announced on 29 March 2013 and will run until 29 April 2013.
 
Version under review
PR-VOTable-1.3-20130315
RFC Review Period
29 March 2013 - 29 April 2013

Change Overview

Changed:
<
<
Changes since the previous version 1.2 are mainly in the areas of
>
>
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.
Deleted:
<
<
representation of null values and serialization. A detailed list of the changes is available in section 9.2 of the document.
 
Changed:
<
<
This version of the document has been developed within the public
>
>
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.
Deleted:
<
<
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:

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

Changed:
<
<


>
>


 
Changed:
<
<
In order to add a comment to the document, please edit this page
>
>
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.
Deleted:
<
<
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.
 
Changed:
<
<
Additional discussion about any of the comments or responses
>
>
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.
Deleted:
<
<
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.
 
Changed:
<
<

>
>

 

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

Added:
>
>
 (please add comments here)
Changed:
<
<

>
>

 

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

Added:
>
>
 (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).
Added:
>
>

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


 

Revision 12013-03-28 - MarkTaylor

 
META TOPICPARENT name="WebPreferences"

<--  
-->

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
RFC Review Period
29 March 2013 - 29 April 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:

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 Match 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).
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback