Difference: VOTableInfo (1 vs. 5)

Revision 52019-10-14 - TomDonaldson

 
META TOPICPARENT name="IvoaApplications"

VOTable

VOTable is a standard for the interchange of data represented as a set of tables, and includes both table metadata and the data itself.

The Application Working Group assumed responsibility for VOTable with version 1.3 when the VOTable Working Group was retired.

Recommendation History

See IVOA Document Versions for the official list of all IVOA documents and versions.

Standard Release Date
VOTable 1.3 20 September 2013
VOTable 1.2 30 November 2009
VOTable 1.1 11 August 2004

In Progress

Summary

We are currently working on VOTable 1.4, which is a backward-compatible revision to support a new TIMESYS element and other miscellaneous cleanup. See also the original note: A Proposal for a TIMESYS Element in VOTable

Latest Draft

VOTable 1.4 (Working Draft)

Please add comments, concerns, and implementation notes to this RFC page: VOTable 1.4 Request For Comments

Past Drafts

See: VOTable 1.4 Working Draft Notes

Future

Consider for future version Reference Earliest Version Notes
Changed:
<
<
Port the VOTable source to ivoatex. email 1.5 Markus has valiantly volunteered.
>
>
Port the VOTable source to ivoatex. email 1.5  
 
DataLink recommends using a "content" parameter. Consider mentioning it in sec. 8 (MIME types) to avoid other standards reinventing the same thing with a different name. email 1.5  

Add optional "refposition" attribute to COOSYS.

Or maybe "refposition" should be required?

email email2

1.4 RFC Discussion

1.5 (or 2.0 refposition is required)  
Remove mention of UType in section 1.4, as it is lacking a standard. email 1.5  
Sec. 4.6: Remove paragraph "In order to avoid name collisions..." email 1.5  

The current guidance on versioning is that the namespace URI should remain constant for all minor revs of a major version. That's fine, but I think the added feature of having that URI be a URL to the latest schema version is more confusing than convenient.

The biggest problem for VOTable is that the schema now has to allow multiple version attributes (e.g., 1.3 and 1.4) to support backward compatibility, while at the same time allowing 1.4-only features like TIMESYS. This makes the schema somewhat inaccurate as it allows version="1.3" and TIMESYS in the same document.

I would be happy to remove the convenience of having the namespace URI point to the latest schema. For VOTable writers that want to specify the schema (not required), they may as well point to the specific version. They know the version since they already must specify the version="1.x" attribute.

That discussion is outside the scope of VOTable itself, so if that remains unchanged, I propose that we recommend using the specific version schema URL instead of the namespace URI if referencing the schema.

Suggestion by Tom Donaldson 1.5  

People here at CDS have been playing around the TIMESYS with example taken in VizieR. This really shows that in many cases a "double"-valued (or more) ref should be a great help. The solution could be to change the definition of ref in VOTable schema from IDref to IDrefs. This was discussed at the time of the TIMESYS note was made public and Mark T said it could have consequences to be addressed. Such a mechanism could also enter in competition with "ref" set on GROUPS. So I agree this may be a too long discussion. But this should be set in the Notes as something to tackle in version 1.5

email 1.5  

decimal years representations in 3.5 : usage of besselian or julian years for timestamps apart from making timeorigin un-useful (and then forbidden) also implies some inference on the timescale used (see the TIME WCS paper for references and discussion). I suggest to add the the following sentence at the end of "timeorigin" explanation: "When using calendar epochs written in yr or Ba, note that conventionally Julian years are tied to the TDB timescale and Besselian years to ET (written here as TT) (Rots and Bunclark et al., 2015)." By the way, on a related topic I discover that in 3.4 COOSYS, we don't explicitly constrain the representation of time in equinox and epoch attributes. This however clear in the xml schema. I suggest adding after "... the epoch of the positions if necessary", the following sentence: " Both equinox and epoch MUST be expressed in the Julian or Besselian calendar".

email ??  
Add a table of definitions for allowed COOSYS "system" attribute values. 1.4 RFC Comment 1.5 If uncontroversial, could be done during 1.4 RFC period.

Make COOSYS and TIMESYS more consistent:

  • State that COOSYS and TIMESYS elements MUST be defined prior to their first reference. Currently COOSYS is only a SHOULD, and only for that case of a reference via "ref".
  • State that references to COOSYS and TIMESYS must be referenced via a "ref" attribute. Currently references to COOSYS are allowed to be implicit.

1.4 RFC Comment as well as previous discussions 2.0 The only reason these weren't done for 1.4 were to preserve backward compatibility.
The example in 3.7, where a LINK element is used to reference a SKOS concept, is using an outdated and abandoned vocabulary (on purl.org). Update this when a new-style physical quantities is ready (or just remove the outdated reference). 1.4 RFC Comment 1.5  

Historical Information

<-- -->

Revision 42019-08-16 - TomDonaldson

 
META TOPICPARENT name="IvoaApplications"

VOTable

VOTable is a standard for the interchange of data represented as a set of tables, and includes both table metadata and the data itself.

The Application Working Group assumed responsibility for VOTable with version 1.3 when the VOTable Working Group was retired.

Recommendation History

See IVOA Document Versions for the official list of all IVOA documents and versions.

Standard Release Date
VOTable 1.3 20 September 2013
VOTable 1.2 30 November 2009
VOTable 1.1 11 August 2004

In Progress

Summary

We are currently working on VOTable 1.4, which is a backward-compatible revision to support a new TIMESYS element and other miscellaneous cleanup. See also the original note: A Proposal for a TIMESYS Element in VOTable

Latest Draft

VOTable 1.4 (Working Draft)

Please add comments, concerns, and implementation notes to this RFC page: VOTable 1.4 Request For Comments

Past Drafts

See: VOTable 1.4 Working Draft Notes

Future

Changed:
<
<
Consider for future version Reference Major/Minor Notes
Port the VOTable source to ivoatex. email Minor Markus has valiantly volunteered.
DataLink recommends using a "content" parameter. Consider mentioning it in sec. 8 (MIME types) to avoid other standards reinventing the same thing with a different name. email Minor  
Add optional "origin" or "refposition" attribute to COOSYS email Minor  
Remove mention of UType in section 1.4, as it is lacking a standard. email Minor  
Sec. 4.6: Remove paragraph "In order to avoid name collisions..." email Minor  

The current guidance on versioning is that the namespace URI should remain constant for all minor revs of a major version. That's fine, but I think the added feature of having that URI be a URL to the latest schema version is more confusing than convenient.

The biggest problem for VOTable is that the schema now has to allow multiple version attributes (e.g., 1.3 and 1.4) to support backward compatibility, while at the same time allowing 1.4-only features like TIMESYS. This makes the schema somewhat inaccurate as it allows version="1.3" and TIMESYS in the same document.

I would be happy to remove the convenience of having the namespace URI point to the latest schema. For VOTable writers that want to specify the schema (not required), they may as well point to the specific version. They know the version since they already must specify the version="1.x" attribute.

That discussion is outside the scope of VOTable itself, so if that remains unchanged, I propose that we recommend using the specific version schema URL instead of the namespace URI if referencing the schema.

     

delaying refposition attribute in COOSYS. I understood that Arnold has strong arguments that when we have COOSYS and TIMESYS they would have to share the same refposition which is something will should be explained clearly in the text in case this COOSYS addition would have been validated. I also understand that as a matter of consequence the refposition in TIMESYS is also valid for an associated COOSYS. But in case we only have COOSYS, this refposition is strongly missing. So if we delay that to 1.5 we should at least reinforce he need for this change in the Notes.

email    

People here at CDS have been playing around the TIMESYS with example taken in VizieR. This really shows that in many cases a "double"-valued (or more) ref should be a great help. The solution could be to change the definition of ref in VOTable schema from IDref to IDrefs. This was discussed at the time of the TIMESYS note was made public and Mark T said it could have consequences to be addressed. Such a mechanism could also enter in competition with "ref" set on GROUPS. So I agree this may be a too long discussion. But this should be set in the Notes as something to tackle in version 1.5

email    

decimal years representations in 3.5 : usage of besselian or julian years for timestamps apart from making timeorigin un-useful (and then forbidden) also implies some inference on the timescale used (see the TIME WCS paper for references and discussion). I suggest to add the the following sentence at the end of "timeorigin" explanation: "When using calendar epochs written in yr or Ba, note that conventionally Julian years are tied to the TDB timescale and Besselian years to ET (written here as TT) (Rots and Bunclark et al., 2015)." By the way, on a related topic I discover that in 3.4 COOSYS, we don't explicitly constrain the representation of time in equinox and epoch attributes. This however clear in the xml schema. I suggest adding after "... the epoch of the positions if necessary", the following sentence: " Both equinox and epoch MUST be expressed in the Julian or Besselian calendar".

email    
>
>
Consider for future version Reference Earliest Version Notes
Port the VOTable source to ivoatex. email 1.5 Markus has valiantly volunteered.
DataLink recommends using a "content" parameter. Consider mentioning it in sec. 8 (MIME types) to avoid other standards reinventing the same thing with a different name. email 1.5  

Add optional "refposition" attribute to COOSYS.

Or maybe "refposition" should be required?

email email2

1.4 RFC Discussion

1.5 (or 2.0 refposition is required)  
Remove mention of UType in section 1.4, as it is lacking a standard. email 1.5  
Sec. 4.6: Remove paragraph "In order to avoid name collisions..." email 1.5  

The current guidance on versioning is that the namespace URI should remain constant for all minor revs of a major version. That's fine, but I think the added feature of having that URI be a URL to the latest schema version is more confusing than convenient.

The biggest problem for VOTable is that the schema now has to allow multiple version attributes (e.g., 1.3 and 1.4) to support backward compatibility, while at the same time allowing 1.4-only features like TIMESYS. This makes the schema somewhat inaccurate as it allows version="1.3" and TIMESYS in the same document.

I would be happy to remove the convenience of having the namespace URI point to the latest schema. For VOTable writers that want to specify the schema (not required), they may as well point to the specific version. They know the version since they already must specify the version="1.x" attribute.

That discussion is outside the scope of VOTable itself, so if that remains unchanged, I propose that we recommend using the specific version schema URL instead of the namespace URI if referencing the schema.

Suggestion by Tom Donaldson 1.5  

People here at CDS have been playing around the TIMESYS with example taken in VizieR. This really shows that in many cases a "double"-valued (or more) ref should be a great help. The solution could be to change the definition of ref in VOTable schema from IDref to IDrefs. This was discussed at the time of the TIMESYS note was made public and Mark T said it could have consequences to be addressed. Such a mechanism could also enter in competition with "ref" set on GROUPS. So I agree this may be a too long discussion. But this should be set in the Notes as something to tackle in version 1.5

email 1.5  

decimal years representations in 3.5 : usage of besselian or julian years for timestamps apart from making timeorigin un-useful (and then forbidden) also implies some inference on the timescale used (see the TIME WCS paper for references and discussion). I suggest to add the the following sentence at the end of "timeorigin" explanation: "When using calendar epochs written in yr or Ba, note that conventionally Julian years are tied to the TDB timescale and Besselian years to ET (written here as TT) (Rots and Bunclark et al., 2015)." By the way, on a related topic I discover that in 3.4 COOSYS, we don't explicitly constrain the representation of time in equinox and epoch attributes. This however clear in the xml schema. I suggest adding after "... the epoch of the positions if necessary", the following sentence: " Both equinox and epoch MUST be expressed in the Julian or Besselian calendar".

email ??  
Add a table of definitions for allowed COOSYS "system" attribute values. 1.4 RFC Comment 1.5 If uncontroversial, could be done during 1.4 RFC period.
Added:
>
>

Make COOSYS and TIMESYS more consistent:

  • State that COOSYS and TIMESYS elements MUST be defined prior to their first reference. Currently COOSYS is only a SHOULD, and only for that case of a reference via "ref".
  • State that references to COOSYS and TIMESYS must be referenced via a "ref" attribute. Currently references to COOSYS are allowed to be implicit.

1.4 RFC Comment as well as previous discussions 2.0 The only reason these weren't done for 1.4 were to preserve backward compatibility.
The example in 3.7, where a LINK element is used to reference a SKOS concept, is using an outdated and abandoned vocabulary (on purl.org). Update this when a new-style physical quantities is ready (or just remove the outdated reference). 1.4 RFC Comment 1.5  
 

Historical Information

<-- -->

Revision 32019-07-08 - TomDonaldson

 
META TOPICPARENT name="IvoaApplications"

VOTable

VOTable is a standard for the interchange of data represented as a set of tables, and includes both table metadata and the data itself.

The Application Working Group assumed responsibility for VOTable with version 1.3 when the VOTable Working Group was retired.

Recommendation History

See IVOA Document Versions for the official list of all IVOA documents and versions.

Standard Release Date
VOTable 1.3 20 September 2013
VOTable 1.2 30 November 2009
VOTable 1.1 11 August 2004

In Progress

Summary

We are currently working on VOTable 1.4, which is a backward-compatible revision to support a new TIMESYS element and other miscellaneous cleanup. See also the original note: A Proposal for a TIMESYS Element in VOTable

Latest Draft

VOTable 1.4 (Working Draft)

Please add comments, concerns, and implementation notes to this RFC page: VOTable 1.4 Request For Comments

Past Drafts

See: VOTable 1.4 Working Draft Notes

Changed:
<
<

Future

>
>

Future

 
Consider for future version Reference Major/Minor Notes
Port the VOTable source to ivoatex. email Minor Markus has valiantly volunteered.
DataLink recommends using a "content" parameter. Consider mentioning it in sec. 8 (MIME types) to avoid other standards reinventing the same thing with a different name. email Minor  
Add optional "origin" or "refposition" attribute to COOSYS email Minor  
Remove mention of UType in section 1.4, as it is lacking a standard. email Minor  
Sec. 4.6: Remove paragraph "In order to avoid name collisions..." email Minor  

The current guidance on versioning is that the namespace URI should remain constant for all minor revs of a major version. That's fine, but I think the added feature of having that URI be a URL to the latest schema version is more confusing than convenient.

The biggest problem for VOTable is that the schema now has to allow multiple version attributes (e.g., 1.3 and 1.4) to support backward compatibility, while at the same time allowing 1.4-only features like TIMESYS. This makes the schema somewhat inaccurate as it allows version="1.3" and TIMESYS in the same document.

I would be happy to remove the convenience of having the namespace URI point to the latest schema. For VOTable writers that want to specify the schema (not required), they may as well point to the specific version. They know the version since they already must specify the version="1.x" attribute.

That discussion is outside the scope of VOTable itself, so if that remains unchanged, I propose that we recommend using the specific version schema URL instead of the namespace URI if referencing the schema.

     

delaying refposition attribute in COOSYS. I understood that Arnold has strong arguments that when we have COOSYS and TIMESYS they would have to share the same refposition which is something will should be explained clearly in the text in case this COOSYS addition would have been validated. I also understand that as a matter of consequence the refposition in TIMESYS is also valid for an associated COOSYS. But in case we only have COOSYS, this refposition is strongly missing. So if we delay that to 1.5 we should at least reinforce he need for this change in the Notes.

email    

People here at CDS have been playing around the TIMESYS with example taken in VizieR. This really shows that in many cases a "double"-valued (or more) ref should be a great help. The solution could be to change the definition of ref in VOTable schema from IDref to IDrefs. This was discussed at the time of the TIMESYS note was made public and Mark T said it could have consequences to be addressed. Such a mechanism could also enter in competition with "ref" set on GROUPS. So I agree this may be a too long discussion. But this should be set in the Notes as something to tackle in version 1.5

email    

decimal years representations in 3.5 : usage of besselian or julian years for timestamps apart from making timeorigin un-useful (and then forbidden) also implies some inference on the timescale used (see the TIME WCS paper for references and discussion). I suggest to add the the following sentence at the end of "timeorigin" explanation: "When using calendar epochs written in yr or Ba, note that conventionally Julian years are tied to the TDB timescale and Besselian years to ET (written here as TT) (Rots and Bunclark et al., 2015)." By the way, on a related topic I discover that in 3.4 COOSYS, we don't explicitly constrain the representation of time in equinox and epoch attributes. This however clear in the xml schema. I suggest adding after "... the epoch of the positions if necessary", the following sentence: " Both equinox and epoch MUST be expressed in the Julian or Besselian calendar".

email    

Historical Information

<-- -->

Revision 22019-06-03 - TomDonaldson

 
META TOPICPARENT name="IvoaApplications"

VOTable

VOTable is a standard for the interchange of data represented as a set of tables, and includes both table metadata and the data itself.

The Application Working Group assumed responsibility for VOTable with version 1.3 when the VOTable Working Group was retired.

Recommendation History

See IVOA Document Versions for the official list of all IVOA documents and versions.

Standard Release Date
VOTable 1.3 20 September 2013
VOTable 1.2 30 November 2009
VOTable 1.1 11 August 2004

In Progress

Summary

We are currently working on VOTable 1.4, which is a backward-compatible revision to support a new TIMESYS element and other miscellaneous cleanup. See also the original note: A Proposal for a TIMESYS Element in VOTable

Latest Draft

VOTable 1.4 (Working Draft)

Please add comments, concerns, and implementation notes to this RFC page: VOTable 1.4 Request For Comments

Past Drafts

See: VOTable 1.4 Working Draft Notes

Future

Consider for future version Reference Major/Minor Notes
Port the VOTable source to ivoatex. email Minor Markus has valiantly volunteered.
DataLink recommends using a "content" parameter. Consider mentioning it in sec. 8 (MIME types) to avoid other standards reinventing the same thing with a different name. email Minor  
Add optional "origin" or "refposition" attribute to COOSYS email Minor  
Remove mention of UType in section 1.4, as it is lacking a standard. email Minor  
Sec. 4.6: Remove paragraph "In order to avoid name collisions..." email Minor  
Changed:
<
<
       
>
>

The current guidance on versioning is that the namespace URI should remain constant for all minor revs of a major version. That's fine, but I think the added feature of having that URI be a URL to the latest schema version is more confusing than convenient.

The biggest problem for VOTable is that the schema now has to allow multiple version attributes (e.g., 1.3 and 1.4) to support backward compatibility, while at the same time allowing 1.4-only features like TIMESYS. This makes the schema somewhat inaccurate as it allows version="1.3" and TIMESYS in the same document.

I would be happy to remove the convenience of having the namespace URI point to the latest schema. For VOTable writers that want to specify the schema (not required), they may as well point to the specific version. They know the version since they already must specify the version="1.x" attribute.

That discussion is outside the scope of VOTable itself, so if that remains unchanged, I propose that we recommend using the specific version schema URL instead of the namespace URI if referencing the schema.

     
Added:
>
>

delaying refposition attribute in COOSYS. I understood that Arnold has strong arguments that when we have COOSYS and TIMESYS they would have to share the same refposition which is something will should be explained clearly in the text in case this COOSYS addition would have been validated. I also understand that as a matter of consequence the refposition in TIMESYS is also valid for an associated COOSYS. But in case we only have COOSYS, this refposition is strongly missing. So if we delay that to 1.5 we should at least reinforce he need for this change in the Notes.

email    

People here at CDS have been playing around the TIMESYS with example taken in VizieR. This really shows that in many cases a "double"-valued (or more) ref should be a great help. The solution could be to change the definition of ref in VOTable schema from IDref to IDrefs. This was discussed at the time of the TIMESYS note was made public and Mark T said it could have consequences to be addressed. Such a mechanism could also enter in competition with "ref" set on GROUPS. So I agree this may be a too long discussion. But this should be set in the Notes as something to tackle in version 1.5

email    

decimal years representations in 3.5 : usage of besselian or julian years for timestamps apart from making timeorigin un-useful (and then forbidden) also implies some inference on the timescale used (see the TIME WCS paper for references and discussion). I suggest to add the the following sentence at the end of "timeorigin" explanation: "When using calendar epochs written in yr or Ba, note that conventionally Julian years are tied to the TDB timescale and Besselian years to ET (written here as TT) (Rots and Bunclark et al., 2015)." By the way, on a related topic I discover that in 3.4 COOSYS, we don't explicitly constrain the representation of time in equinox and epoch attributes. This however clear in the xml schema. I suggest adding after "... the epoch of the positions if necessary", the following sentence: " Both equinox and epoch MUST be expressed in the Julian or Besselian calendar".

email    
 

Historical Information

Changed:
<
<

Revision 12019-05-03 - TomDonaldson

 
META TOPICPARENT name="IvoaApplications"

VOTable

VOTable is a standard for the interchange of data represented as a set of tables, and includes both table metadata and the data itself.

The Application Working Group assumed responsibility for VOTable with version 1.3 when the VOTable Working Group was retired.

Recommendation History

See IVOA Document Versions for the official list of all IVOA documents and versions.

Standard Release Date
VOTable 1.3 20 September 2013
VOTable 1.2 30 November 2009
VOTable 1.1 11 August 2004

In Progress

Summary

We are currently working on VOTable 1.4, which is a backward-compatible revision to support a new TIMESYS element and other miscellaneous cleanup. See also the original note: A Proposal for a TIMESYS Element in VOTable

Latest Draft

VOTable 1.4 (Working Draft)

Please add comments, concerns, and implementation notes to this RFC page: VOTable 1.4 Request For Comments

Past Drafts

See: VOTable 1.4 Working Draft Notes

Future

Consider for future version Reference Major/Minor Notes
Port the VOTable source to ivoatex. email Minor Markus has valiantly volunteered.
DataLink recommends using a "content" parameter. Consider mentioning it in sec. 8 (MIME types) to avoid other standards reinventing the same thing with a different name. email Minor  
Add optional "origin" or "refposition" attribute to COOSYS email Minor  
Remove mention of UType in section 1.4, as it is lacking a standard. email Minor  
Sec. 4.6: Remove paragraph "In order to avoid name collisions..." email Minor  
       

Historical Information

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