Difference: RI11RFC (1 vs. 20)

Revision 202017-10-23 - TheresaDower

 
META TOPICPARENT name="IvoaResReg"

Registry Interfaces 1.1 Proposed Recommendation: Request for Comments

Public discusion page for the IVOA Registry Interfaces 1.1 Proposed Recommendation

Changed:
<
<
The latest version of the RI 1.1 specification can be found at: http://www.ivoa.net/documents/RegistryInterface/20170201/
>
>
The latest version of the RI 1.1 specification can be found at: http://ivoa.net/documents/RegistryInterface/20171010/ . This version includes comments from the TCG during the RFC period.
 
Added:
>
>
The original RFC document is: http://www.ivoa.net/documents/RegistryInterface/20170201/
 In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Discussion about any of the comments or responses should be conducted on the registry mailing list, registry@ivoa.net . However, please be sure to enter your initial comments here for full consideration in any future revisions of this document.

Comments from the IVOA Community and TCG members during RFC period: 2017-02-07 - 2017-03-07

Comments from Mark Taylor

Document looks clear, and I support moving to a version that drops the SOAP-based client interfaces. I fixed some extremely minor typos in volute. One question (just curiosity really): what's the reason for introducing the new requirement for time granularity at the level of seconds that's mentioned in section 2.7? -- MarkTaylor - 2017-03-08

  • Without this requirement, a client has to retrieve an Identify response from a service to figure out what arguments it can pass. Everyone had implemented seconds granularity anyway, so it seemed reasonable to do away with one "free parameter". -- MarkusDemleitner - 2017-04-04


Comments from the TCG during the TCG Review Period

TCG Chair & Vice Chair _(Matthew Graham, Pat Dowler)

Applications Working Group _(Pierre Fernique, Tom Donaldson)

Two minor typos detected:

  • Page 10 "regiestries" -> registries
  • page 15 - "theListRecords" -> missing space after "the"
Apps approves this document. -- PierreFernique - 2017-05-10

Data Access Layer Working Group (Francois Bonnarel, Marco Molinaro)

This document is actually really different from version 1.0. Some people may be lost. For newcomers, the introduction should clarify a bit immediately that registry search was done by SOAP and that currently the recommended standard method to query a registry is RegTAP. The document sometimes quotes "version 1" and sometimes "version 1.0" or "specification 1.0" We recommend using "version 1.0" or "version 1.1" (when appropriate) everywhere. Appart from these two minor points we approve this document. -- FrancoisBonnarel - 2017-08-21 -- MarcoMolinaro - 2017-08-21

I agree this is a fairly major departure for a 1.1 document, and it's worth noting. I've added a section in the introduction noting the removal of SOAP as a recommendation and addition of RegTAP plus encouragement of other future standards. I also changed "version 1" to "version 1.0" where I'd missed it, and am reviewing places where we may want to say "version" of the document as a whole rather than specification of a schema itself, a carryover from prior versions of the document. Thank you. -- TheresaDower - 2017-08-22

Data Model Working Group _(Mark Cresitello-Dittmar, Laurent Michel)

I have reviewed the 2017-04-03 version of the PR.

There is one typo that I noticed on pg 10, 'no' description has lost an 'a' in the break up of unavailable.. 'un-vailable'

DM approves this document. -- MarkCresitelloDittmar - 2017-05-11

Typo fixed in svn for the next build of the document; thank you. -- TheresaDower - 2017-05-16

Grid & Web Services Working Group (Brian Major, Giuliano Taffoni)

Since VOSI 1.1 is also near the end of RFC, could we update the reference to the 1.1 version instead of 1.0? It won't put any more burden on this spec than the 1.0 version does.

I think, in the capabilities example in Appendix C, it should be maxReturnRecords rather than maxRecords. (See: VOResource http://ivoa.net/documents/VOResource/20170425/PR-VOResource-1.1-20170425.html)

Also in the capabilities example: I'm not sure what the extensionSearchSupport element is... I see that it's in the SOAP based schema, but I don't see it in VOResource.

-- BrianMajor - 2017-05-03

I support the change to VOSI 1.1 since it won't affect existing implementations of this spec and will change it in the RI1.1 document text absent strong objections.

In the capabilities examples, "maxRecords" is the element in the vg:Registry extension as defined in v1.0 of Registry Interfaces. I agree from the VOResource spec that MaxReturnRecords would be more appropriate, but we are intending to keep this a backward-compatible v1.x document. Given that maxRecords is used in client and inter-registry harvesting processes, changing this element could break a good deal of infrastructure. If we move to a version 2.0 of this document in the future, I would like to incorporate this change, but not in 1.1.

The extensionSearchSupport element is a deprecated tag from RI 1.0 intended to report whether the SOAP search capability of a searchable registry would handle only core VOResource elements or extension metadata, like capabilities. Since we are dropping the SOAP search capability but remaining a 1.x version document, it is deprecated but not removed. This can also be changed in 2.0.

-- TheresaDower - 2017-05-10

Okay, thanks Theresa. With the VOSI 1.1 change above I approve this document.

-- BrianMajor - 2017-05-10

Registry Working Group _(Markus Demleitner, Theresa Dower)

Registry, unsurprisingly, approves.

-- MarkusDemleitner - 2017-04-04

Semantics Working Group _(Mireille Louys, Alberto Accomazzi)

Editorial comments :

section 1.2 : has a citation and links to the VOResource specification, but no link to the IVOA identifiers
specification , which would help to identify the related documents


section 2.2
OAI-PMH decuments --> documents

Changed:
<
<
Appendix B 'The VORegistry Schema' reads xmlns:vm="http://www.ivoa.net/xml/VOMetadata/v0.1" which is not defined in the ivoa.net . ? is it a typo, remains from previous versions?
>
>
Appendix B 'The VORegistry Schema' reads xmlns:vm="http://www.ivoa.net/xml/VOMetadata/v0.1" which is not defined in the ivoa.net . ? is it a typo, remains from previous versions?
  In the "References" section, Readibility :

The document explains the actions planned for managing the network of VO registries, but some guide lines for the new comer to grasp all the interconnected concepts: VOResource, Services, Data collections, etc. should be given. A map, graph of the Registry ecosystem, as didactically described in the Proposed Endorsed Note "Discovering data collections Within Services" could be added in this spec and in VOResource as well, or at least included at the top of the Registry wiki pages.

I approve the document, and hope this request for a didactic add-on to the set of Registry related documents would be considered positively.

-- MireilleLouys - 2017-08-24

Education Interest Group _(Massimo Ramella, Sudhanshu Barway)

Time Domain Interest Group _(John Swinbank, Mike Fitzpatrick)

Data Curation & Preservation Interest Group (Francoise Genova)

Operations Interest Group _(Tom McGlynn, Mark Taylor)

Revision 192017-08-24 - MireilleLouys

 
META TOPICPARENT name="IvoaResReg"

Registry Interfaces 1.1 Proposed Recommendation: Request for Comments

Public discusion page for the IVOA Registry Interfaces 1.1 Proposed Recommendation

The latest version of the RI 1.1 specification can be found at: http://www.ivoa.net/documents/RegistryInterface/20170201/

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Discussion about any of the comments or responses should be conducted on the registry mailing list, registry@ivoa.net . However, please be sure to enter your initial comments here for full consideration in any future revisions of this document.

Comments from the IVOA Community and TCG members during RFC period: 2017-02-07 - 2017-03-07

Comments from Mark Taylor

Document looks clear, and I support moving to a version that drops the SOAP-based client interfaces. I fixed some extremely minor typos in volute. One question (just curiosity really): what's the reason for introducing the new requirement for time granularity at the level of seconds that's mentioned in section 2.7? -- MarkTaylor - 2017-03-08

  • Without this requirement, a client has to retrieve an Identify response from a service to figure out what arguments it can pass. Everyone had implemented seconds granularity anyway, so it seemed reasonable to do away with one "free parameter". -- MarkusDemleitner - 2017-04-04


Comments from the TCG during the TCG Review Period

TCG Chair & Vice Chair _(Matthew Graham, Pat Dowler)

Applications Working Group _(Pierre Fernique, Tom Donaldson)

Two minor typos detected:

  • Page 10 "regiestries" -> registries
  • page 15 - "theListRecords" -> missing space after "the"
Apps approves this document. -- PierreFernique - 2017-05-10

Data Access Layer Working Group (Francois Bonnarel, Marco Molinaro)

This document is actually really different from version 1.0. Some people may be lost. For newcomers, the introduction should clarify a bit immediately that registry search was done by SOAP and that currently the recommended standard method to query a registry is RegTAP. The document sometimes quotes "version 1" and sometimes "version 1.0" or "specification 1.0" We recommend using "version 1.0" or "version 1.1" (when appropriate) everywhere. Appart from these two minor points we approve this document. -- FrancoisBonnarel - 2017-08-21 -- MarcoMolinaro - 2017-08-21

I agree this is a fairly major departure for a 1.1 document, and it's worth noting. I've added a section in the introduction noting the removal of SOAP as a recommendation and addition of RegTAP plus encouragement of other future standards. I also changed "version 1" to "version 1.0" where I'd missed it, and am reviewing places where we may want to say "version" of the document as a whole rather than specification of a schema itself, a carryover from prior versions of the document. Thank you. -- TheresaDower - 2017-08-22

Data Model Working Group _(Mark Cresitello-Dittmar, Laurent Michel)

I have reviewed the 2017-04-03 version of the PR.

There is one typo that I noticed on pg 10, 'no' description has lost an 'a' in the break up of unavailable.. 'un-vailable'

DM approves this document. -- MarkCresitelloDittmar - 2017-05-11

Typo fixed in svn for the next build of the document; thank you. -- TheresaDower - 2017-05-16

Grid & Web Services Working Group (Brian Major, Giuliano Taffoni)

Since VOSI 1.1 is also near the end of RFC, could we update the reference to the 1.1 version instead of 1.0? It won't put any more burden on this spec than the 1.0 version does.

I think, in the capabilities example in Appendix C, it should be maxReturnRecords rather than maxRecords. (See: VOResource http://ivoa.net/documents/VOResource/20170425/PR-VOResource-1.1-20170425.html)

Also in the capabilities example: I'm not sure what the extensionSearchSupport element is... I see that it's in the SOAP based schema, but I don't see it in VOResource.

-- BrianMajor - 2017-05-03

I support the change to VOSI 1.1 since it won't affect existing implementations of this spec and will change it in the RI1.1 document text absent strong objections.

In the capabilities examples, "maxRecords" is the element in the vg:Registry extension as defined in v1.0 of Registry Interfaces. I agree from the VOResource spec that MaxReturnRecords would be more appropriate, but we are intending to keep this a backward-compatible v1.x document. Given that maxRecords is used in client and inter-registry harvesting processes, changing this element could break a good deal of infrastructure. If we move to a version 2.0 of this document in the future, I would like to incorporate this change, but not in 1.1.

The extensionSearchSupport element is a deprecated tag from RI 1.0 intended to report whether the SOAP search capability of a searchable registry would handle only core VOResource elements or extension metadata, like capabilities. Since we are dropping the SOAP search capability but remaining a 1.x version document, it is deprecated but not removed. This can also be changed in 2.0.

-- TheresaDower - 2017-05-10

Okay, thanks Theresa. With the VOSI 1.1 change above I approve this document.

-- BrianMajor - 2017-05-10

Registry Working Group _(Markus Demleitner, Theresa Dower)

Registry, unsurprisingly, approves.

-- MarkusDemleitner - 2017-04-04

Semantics Working Group _(Mireille Louys, Alberto Accomazzi)

Editorial comments :

Added:
>
>
section 1.2 : has a citation and links to the VOResource specification, but no link to the IVOA identifiers
specification , which would help to identify the related documents


section 2.2
OAI-PMH decuments --> documents

Appendix B 'The VORegistry Schema' reads xmlns:vm="http://www.ivoa.net/xml/VOMetadata/v0.1" which is not defined in the ivoa.net . ? is it a typo, remains from previous versions?

 In the "References" section, Readibility :

The document explains the actions planned for managing the network of VO registries, but some guide lines for the new comer to grasp all the interconnected concepts: VOResource, Services, Data collections, etc. should be given. A map, graph of the Registry ecosystem, as didactically described in the Proposed Endorsed Note "Discovering data collections Within Services" could be added in this spec and in VOResource as well, or at least included at the top of the Registry wiki pages.

Changed:
<
<
I approve the document, provided this request for a didactic add-on would be considered positively.
>
>
I approve the document, and hope this request for a didactic add-on to the set of Registry related documents would be considered positively.
  -- MireilleLouys - 2017-08-24

Education Interest Group _(Massimo Ramella, Sudhanshu Barway)

Time Domain Interest Group _(John Swinbank, Mike Fitzpatrick)

Data Curation & Preservation Interest Group (Francoise Genova)

Operations Interest Group _(Tom McGlynn, Mark Taylor)

Revision 182017-08-24 - MireilleLouys

 
META TOPICPARENT name="IvoaResReg"

Registry Interfaces 1.1 Proposed Recommendation: Request for Comments

Public discusion page for the IVOA Registry Interfaces 1.1 Proposed Recommendation

The latest version of the RI 1.1 specification can be found at: http://www.ivoa.net/documents/RegistryInterface/20170201/

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Discussion about any of the comments or responses should be conducted on the registry mailing list, registry@ivoa.net . However, please be sure to enter your initial comments here for full consideration in any future revisions of this document.

Comments from the IVOA Community and TCG members during RFC period: 2017-02-07 - 2017-03-07

Comments from Mark Taylor

Document looks clear, and I support moving to a version that drops the SOAP-based client interfaces. I fixed some extremely minor typos in volute. One question (just curiosity really): what's the reason for introducing the new requirement for time granularity at the level of seconds that's mentioned in section 2.7? -- MarkTaylor - 2017-03-08

  • Without this requirement, a client has to retrieve an Identify response from a service to figure out what arguments it can pass. Everyone had implemented seconds granularity anyway, so it seemed reasonable to do away with one "free parameter". -- MarkusDemleitner - 2017-04-04


Comments from the TCG during the TCG Review Period

TCG Chair & Vice Chair _(Matthew Graham, Pat Dowler)

Applications Working Group _(Pierre Fernique, Tom Donaldson)

Two minor typos detected:

  • Page 10 "regiestries" -> registries
  • page 15 - "theListRecords" -> missing space after "the"
Apps approves this document. -- PierreFernique - 2017-05-10

Data Access Layer Working Group (Francois Bonnarel, Marco Molinaro)

This document is actually really different from version 1.0. Some people may be lost. For newcomers, the introduction should clarify a bit immediately that registry search was done by SOAP and that currently the recommended standard method to query a registry is RegTAP. The document sometimes quotes "version 1" and sometimes "version 1.0" or "specification 1.0" We recommend using "version 1.0" or "version 1.1" (when appropriate) everywhere. Appart from these two minor points we approve this document. -- FrancoisBonnarel - 2017-08-21 -- MarcoMolinaro - 2017-08-21

I agree this is a fairly major departure for a 1.1 document, and it's worth noting. I've added a section in the introduction noting the removal of SOAP as a recommendation and addition of RegTAP plus encouragement of other future standards. I also changed "version 1" to "version 1.0" where I'd missed it, and am reviewing places where we may want to say "version" of the document as a whole rather than specification of a schema itself, a carryover from prior versions of the document. Thank you. -- TheresaDower - 2017-08-22

Data Model Working Group _(Mark Cresitello-Dittmar, Laurent Michel)

I have reviewed the 2017-04-03 version of the PR.

There is one typo that I noticed on pg 10, 'no' description has lost an 'a' in the break up of unavailable.. 'un-vailable'

DM approves this document. -- MarkCresitelloDittmar - 2017-05-11

Typo fixed in svn for the next build of the document; thank you. -- TheresaDower - 2017-05-16

Grid & Web Services Working Group (Brian Major, Giuliano Taffoni)

Since VOSI 1.1 is also near the end of RFC, could we update the reference to the 1.1 version instead of 1.0? It won't put any more burden on this spec than the 1.0 version does.

I think, in the capabilities example in Appendix C, it should be maxReturnRecords rather than maxRecords. (See: VOResource http://ivoa.net/documents/VOResource/20170425/PR-VOResource-1.1-20170425.html)

Also in the capabilities example: I'm not sure what the extensionSearchSupport element is... I see that it's in the SOAP based schema, but I don't see it in VOResource.

-- BrianMajor - 2017-05-03

I support the change to VOSI 1.1 since it won't affect existing implementations of this spec and will change it in the RI1.1 document text absent strong objections.

In the capabilities examples, "maxRecords" is the element in the vg:Registry extension as defined in v1.0 of Registry Interfaces. I agree from the VOResource spec that MaxReturnRecords would be more appropriate, but we are intending to keep this a backward-compatible v1.x document. Given that maxRecords is used in client and inter-registry harvesting processes, changing this element could break a good deal of infrastructure. If we move to a version 2.0 of this document in the future, I would like to incorporate this change, but not in 1.1.

The extensionSearchSupport element is a deprecated tag from RI 1.0 intended to report whether the SOAP search capability of a searchable registry would handle only core VOResource elements or extension metadata, like capabilities. Since we are dropping the SOAP search capability but remaining a 1.x version document, it is deprecated but not removed. This can also be changed in 2.0.

-- TheresaDower - 2017-05-10

Okay, thanks Theresa. With the VOSI 1.1 change above I approve this document.

-- BrianMajor - 2017-05-10

Registry Working Group _(Markus Demleitner, Theresa Dower)

Registry, unsurprisingly, approves.

-- MarkusDemleitner - 2017-04-04

Semantics Working Group _(Mireille Louys, Alberto Accomazzi)

Editorial comments :

In the "References" section,

Changed:
<
<
>
>
  • some discrepancies between the urls and the version of the pointed documents appear at various places, due to the fact that "http://www.ivoa.net/documents/{standardName}/" always points to the last version of the document in the IVOA wiki ( ex. TAP) . Could this be fixed by pointing to the document itself?
  • the first url points on this PR document itself. Is it correct to cite http://www.ivoa.net/documents/RegistryInterface/20091104/REC-RegistryInterface-1.0.pdf instead?
Added:
>
>
 Readibility :
Changed:
<
<
The document explains the actions planned for managing the network of VO registries, but some guide lines for the new comer to grasp all the interconnected concepts VOResource, Services, Data collections, etc should be given. A map, graph of the Registry ecosystem, as didactically described in the Proposed Endorsed Note "Discovering data collections Within Services" could be added in this spec and in VOResource as well, or at least included at the top of the Registry wiki pages.
>
>
The document explains the actions planned for managing the network of VO registries, but some guide lines for the new comer to grasp all the interconnected concepts: VOResource, Services, Data collections, etc. should be given. A map, graph of the Registry ecosystem, as didactically described in the Proposed Endorsed Note "Discovering data collections Within Services" could be added in this spec and in VOResource as well, or at least included at the top of the Registry wiki pages.
 
Changed:
<
<
I approve the document, provided this request for a didactic add-on would be considered positively.
>
>
I approve the document, provided this request for a didactic add-on would be considered positively.
 
Changed:
<
<
-- MireilleLouys - 2017-08-23
>
>
-- MireilleLouys - 2017-08-24
Deleted:
<
<
 

Education Interest Group _(Massimo Ramella, Sudhanshu Barway)

Time Domain Interest Group _(John Swinbank, Mike Fitzpatrick)

Data Curation & Preservation Interest Group (Francoise Genova)

Operations Interest Group _(Tom McGlynn, Mark Taylor)

Revision 172017-08-23 - MireilleLouys

 
META TOPICPARENT name="IvoaResReg"

Registry Interfaces 1.1 Proposed Recommendation: Request for Comments

Public discusion page for the IVOA Registry Interfaces 1.1 Proposed Recommendation

The latest version of the RI 1.1 specification can be found at: http://www.ivoa.net/documents/RegistryInterface/20170201/

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Discussion about any of the comments or responses should be conducted on the registry mailing list, registry@ivoa.net . However, please be sure to enter your initial comments here for full consideration in any future revisions of this document.

Comments from the IVOA Community and TCG members during RFC period: 2017-02-07 - 2017-03-07

Comments from Mark Taylor

Document looks clear, and I support moving to a version that drops the SOAP-based client interfaces. I fixed some extremely minor typos in volute. One question (just curiosity really): what's the reason for introducing the new requirement for time granularity at the level of seconds that's mentioned in section 2.7? -- MarkTaylor - 2017-03-08

  • Without this requirement, a client has to retrieve an Identify response from a service to figure out what arguments it can pass. Everyone had implemented seconds granularity anyway, so it seemed reasonable to do away with one "free parameter". -- MarkusDemleitner - 2017-04-04


Comments from the TCG during the TCG Review Period

TCG Chair & Vice Chair _(Matthew Graham, Pat Dowler)

Applications Working Group _(Pierre Fernique, Tom Donaldson)

Two minor typos detected:

  • Page 10 "regiestries" -> registries
  • page 15 - "theListRecords" -> missing space after "the"
Apps approves this document. -- PierreFernique - 2017-05-10

Data Access Layer Working Group (Francois Bonnarel, Marco Molinaro)

This document is actually really different from version 1.0. Some people may be lost. For newcomers, the introduction should clarify a bit immediately that registry search was done by SOAP and that currently the recommended standard method to query a registry is RegTAP. The document sometimes quotes "version 1" and sometimes "version 1.0" or "specification 1.0" We recommend using "version 1.0" or "version 1.1" (when appropriate) everywhere. Appart from these two minor points we approve this document. -- FrancoisBonnarel - 2017-08-21 -- MarcoMolinaro - 2017-08-21

I agree this is a fairly major departure for a 1.1 document, and it's worth noting. I've added a section in the introduction noting the removal of SOAP as a recommendation and addition of RegTAP plus encouragement of other future standards. I also changed "version 1" to "version 1.0" where I'd missed it, and am reviewing places where we may want to say "version" of the document as a whole rather than specification of a schema itself, a carryover from prior versions of the document. Thank you. -- TheresaDower - 2017-08-22

Data Model Working Group _(Mark Cresitello-Dittmar, Laurent Michel)

I have reviewed the 2017-04-03 version of the PR.

There is one typo that I noticed on pg 10, 'no' description has lost an 'a' in the break up of unavailable.. 'un-vailable'

DM approves this document. -- MarkCresitelloDittmar - 2017-05-11

Typo fixed in svn for the next build of the document; thank you. -- TheresaDower - 2017-05-16

Grid & Web Services Working Group (Brian Major, Giuliano Taffoni)

Since VOSI 1.1 is also near the end of RFC, could we update the reference to the 1.1 version instead of 1.0? It won't put any more burden on this spec than the 1.0 version does.

I think, in the capabilities example in Appendix C, it should be maxReturnRecords rather than maxRecords. (See: VOResource http://ivoa.net/documents/VOResource/20170425/PR-VOResource-1.1-20170425.html)

Also in the capabilities example: I'm not sure what the extensionSearchSupport element is... I see that it's in the SOAP based schema, but I don't see it in VOResource.

-- BrianMajor - 2017-05-03

I support the change to VOSI 1.1 since it won't affect existing implementations of this spec and will change it in the RI1.1 document text absent strong objections.

In the capabilities examples, "maxRecords" is the element in the vg:Registry extension as defined in v1.0 of Registry Interfaces. I agree from the VOResource spec that MaxReturnRecords would be more appropriate, but we are intending to keep this a backward-compatible v1.x document. Given that maxRecords is used in client and inter-registry harvesting processes, changing this element could break a good deal of infrastructure. If we move to a version 2.0 of this document in the future, I would like to incorporate this change, but not in 1.1.

The extensionSearchSupport element is a deprecated tag from RI 1.0 intended to report whether the SOAP search capability of a searchable registry would handle only core VOResource elements or extension metadata, like capabilities. Since we are dropping the SOAP search capability but remaining a 1.x version document, it is deprecated but not removed. This can also be changed in 2.0.

-- TheresaDower - 2017-05-10

Okay, thanks Theresa. With the VOSI 1.1 change above I approve this document.

-- BrianMajor - 2017-05-10

Registry Working Group _(Markus Demleitner, Theresa Dower)

Registry, unsurprisingly, approves.

-- MarkusDemleitner - 2017-04-04

Semantics Working Group _(Mireille Louys, Alberto Accomazzi)

Added:
>
>
Editorial comments :

In the "References" section,

Readibility :

The document explains the actions planned for managing the network of VO registries, but some guide lines for the new comer to grasp all the interconnected concepts VOResource, Services, Data collections, etc should be given. A map, graph of the Registry ecosystem, as didactically described in the Proposed Endorsed Note "Discovering data collections Within Services" could be added in this spec and in VOResource as well, or at least included at the top of the Registry wiki pages.

I approve the document, provided this request for a didactic add-on would be considered positively.

-- MireilleLouys - 2017-08-23

 

Education Interest Group _(Massimo Ramella, Sudhanshu Barway)

Time Domain Interest Group _(John Swinbank, Mike Fitzpatrick)

Data Curation & Preservation Interest Group (Francoise Genova)

Operations Interest Group _(Tom McGlynn, Mark Taylor)

Revision 162017-08-22 - TheresaDower

 
META TOPICPARENT name="IvoaResReg"

Registry Interfaces 1.1 Proposed Recommendation: Request for Comments

Public discusion page for the IVOA Registry Interfaces 1.1 Proposed Recommendation

The latest version of the RI 1.1 specification can be found at: http://www.ivoa.net/documents/RegistryInterface/20170201/

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Discussion about any of the comments or responses should be conducted on the registry mailing list, registry@ivoa.net . However, please be sure to enter your initial comments here for full consideration in any future revisions of this document.

Comments from the IVOA Community and TCG members during RFC period: 2017-02-07 - 2017-03-07

Comments from Mark Taylor

Document looks clear, and I support moving to a version that drops the SOAP-based client interfaces. I fixed some extremely minor typos in volute. One question (just curiosity really): what's the reason for introducing the new requirement for time granularity at the level of seconds that's mentioned in section 2.7? -- MarkTaylor - 2017-03-08

  • Without this requirement, a client has to retrieve an Identify response from a service to figure out what arguments it can pass. Everyone had implemented seconds granularity anyway, so it seemed reasonable to do away with one "free parameter". -- MarkusDemleitner - 2017-04-04


Comments from the TCG during the TCG Review Period

TCG Chair & Vice Chair _(Matthew Graham, Pat Dowler)

Applications Working Group _(Pierre Fernique, Tom Donaldson)

Two minor typos detected:

  • Page 10 "regiestries" -> registries
  • page 15 - "theListRecords" -> missing space after "the"
Apps approves this document. -- PierreFernique - 2017-05-10

Data Access Layer Working Group (Francois Bonnarel, Marco Molinaro)

Changed:
<
<
This document is actually really different from version 1.0. Some people may be lost. For newcomers, the introduction should clarify a bit immediately that registry search was done by SOAP and that currently the recommended standard method to query a registry is RegTAP. The document sometimes quotes "version 1" and sometimes "version 1.0" or "specification 1.0" We recommend using "version 1.0" or "version 1.1" (when appropriate) everywhere. Appart from these two minor points we approve this document.
>
>
This document is actually really different from version 1.0. Some people may be lost. For newcomers, the introduction should clarify a bit immediately that registry search was done by SOAP and that currently the recommended standard method to query a registry is RegTAP. The document sometimes quotes "version 1" and sometimes "version 1.0" or "specification 1.0" We recommend using "version 1.0" or "version 1.1" (when appropriate) everywhere. Appart from these two minor points we approve this document. -- FrancoisBonnarel - 2017-08-21 -- MarcoMolinaro - 2017-08-21

I agree this is a fairly major departure for a 1.1 document, and it's worth noting. I've added a section in the introduction noting the removal of SOAP as a recommendation and addition of RegTAP plus encouragement of other future standards. I also changed "version 1" to "version 1.0" where I'd missed it, and am reviewing places where we may want to say "version" of the document as a whole rather than specification of a schema itself, a carryover from prior versions of the document. Thank you. -- TheresaDower - 2017-08-22

Deleted:
<
<
-- FrancoisBonnarel - 2017-08-21 -- MarcoMolinaro - 2017-08-21

 

Data Model Working Group _(Mark Cresitello-Dittmar, Laurent Michel)

I have reviewed the 2017-04-03 version of the PR.

There is one typo that I noticed on pg 10, 'no' description has lost an 'a' in the break up of unavailable.. 'un-vailable'

DM approves this document. -- MarkCresitelloDittmar - 2017-05-11

Typo fixed in svn for the next build of the document; thank you. -- TheresaDower - 2017-05-16

Grid & Web Services Working Group (Brian Major, Giuliano Taffoni)

Since VOSI 1.1 is also near the end of RFC, could we update the reference to the 1.1 version instead of 1.0? It won't put any more burden on this spec than the 1.0 version does.

I think, in the capabilities example in Appendix C, it should be maxReturnRecords rather than maxRecords. (See: VOResource http://ivoa.net/documents/VOResource/20170425/PR-VOResource-1.1-20170425.html)

Also in the capabilities example: I'm not sure what the extensionSearchSupport element is... I see that it's in the SOAP based schema, but I don't see it in VOResource.

-- BrianMajor - 2017-05-03

I support the change to VOSI 1.1 since it won't affect existing implementations of this spec and will change it in the RI1.1 document text absent strong objections.

In the capabilities examples, "maxRecords" is the element in the vg:Registry extension as defined in v1.0 of Registry Interfaces. I agree from the VOResource spec that MaxReturnRecords would be more appropriate, but we are intending to keep this a backward-compatible v1.x document. Given that maxRecords is used in client and inter-registry harvesting processes, changing this element could break a good deal of infrastructure. If we move to a version 2.0 of this document in the future, I would like to incorporate this change, but not in 1.1.

The extensionSearchSupport element is a deprecated tag from RI 1.0 intended to report whether the SOAP search capability of a searchable registry would handle only core VOResource elements or extension metadata, like capabilities. Since we are dropping the SOAP search capability but remaining a 1.x version document, it is deprecated but not removed. This can also be changed in 2.0.

-- TheresaDower - 2017-05-10

Okay, thanks Theresa. With the VOSI 1.1 change above I approve this document.

-- BrianMajor - 2017-05-10

Registry Working Group _(Markus Demleitner, Theresa Dower)

Registry, unsurprisingly, approves.

-- MarkusDemleitner - 2017-04-04

Semantics Working Group _(Mireille Louys, Alberto Accomazzi)

Education Interest Group _(Massimo Ramella, Sudhanshu Barway)

Time Domain Interest Group _(John Swinbank, Mike Fitzpatrick)

Data Curation & Preservation Interest Group (Francoise Genova)

Operations Interest Group _(Tom McGlynn, Mark Taylor)

Revision 152017-08-22 - FrancoisBonnarel

 
META TOPICPARENT name="IvoaResReg"

Registry Interfaces 1.1 Proposed Recommendation: Request for Comments

Public discusion page for the IVOA Registry Interfaces 1.1 Proposed Recommendation

The latest version of the RI 1.1 specification can be found at: http://www.ivoa.net/documents/RegistryInterface/20170201/

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Discussion about any of the comments or responses should be conducted on the registry mailing list, registry@ivoa.net . However, please be sure to enter your initial comments here for full consideration in any future revisions of this document.

Comments from the IVOA Community and TCG members during RFC period: 2017-02-07 - 2017-03-07

Comments from Mark Taylor

Document looks clear, and I support moving to a version that drops the SOAP-based client interfaces. I fixed some extremely minor typos in volute. One question (just curiosity really): what's the reason for introducing the new requirement for time granularity at the level of seconds that's mentioned in section 2.7? -- MarkTaylor - 2017-03-08

  • Without this requirement, a client has to retrieve an Identify response from a service to figure out what arguments it can pass. Everyone had implemented seconds granularity anyway, so it seemed reasonable to do away with one "free parameter". -- MarkusDemleitner - 2017-04-04


Comments from the TCG during the TCG Review Period

TCG Chair & Vice Chair _(Matthew Graham, Pat Dowler)

Applications Working Group _(Pierre Fernique, Tom Donaldson)

Two minor typos detected:

  • Page 10 "regiestries" -> registries
  • page 15 - "theListRecords" -> missing space after "the"
Apps approves this document. -- PierreFernique - 2017-05-10

Data Access Layer Working Group (Francois Bonnarel, Marco Molinaro)

Changed:
<
<
This document is actually really different from version 1.0. Some people may be lost. For newcomers, the introduction should clarify a bit immediatly that registry search was done by SOAP and that currently the recommanded standard method to query a registry is RegTAP. The document sometimes quotes "version 1" and sometimes "version 1.0" or "specification 1.0" We recommand using "version 1.0" or "version 1.1" (when appropriate) everywhere.
>
>
This document is actually really different from version 1.0. Some people may be lost. For newcomers, the introduction should clarify a bit immediately that registry search was done by SOAP and that currently the recommended standard method to query a registry is RegTAP. The document sometimes quotes "version 1" and sometimes "version 1.0" or "specification 1.0" We recommend using "version 1.0" or "version 1.1" (when appropriate) everywhere.
  Appart from these two minor points we approve this document. -- FrancoisBonnarel - 2017-08-21 -- MarcoMolinaro - 2017-08-21

Data Model Working Group _(Mark Cresitello-Dittmar, Laurent Michel)

I have reviewed the 2017-04-03 version of the PR.

There is one typo that I noticed on pg 10, 'no' description has lost an 'a' in the break up of unavailable.. 'un-vailable'

DM approves this document. -- MarkCresitelloDittmar - 2017-05-11

Typo fixed in svn for the next build of the document; thank you. -- TheresaDower - 2017-05-16

Grid & Web Services Working Group (Brian Major, Giuliano Taffoni)

Since VOSI 1.1 is also near the end of RFC, could we update the reference to the 1.1 version instead of 1.0? It won't put any more burden on this spec than the 1.0 version does.

I think, in the capabilities example in Appendix C, it should be maxReturnRecords rather than maxRecords. (See: VOResource http://ivoa.net/documents/VOResource/20170425/PR-VOResource-1.1-20170425.html)

Also in the capabilities example: I'm not sure what the extensionSearchSupport element is... I see that it's in the SOAP based schema, but I don't see it in VOResource.

-- BrianMajor - 2017-05-03

I support the change to VOSI 1.1 since it won't affect existing implementations of this spec and will change it in the RI1.1 document text absent strong objections.

In the capabilities examples, "maxRecords" is the element in the vg:Registry extension as defined in v1.0 of Registry Interfaces. I agree from the VOResource spec that MaxReturnRecords would be more appropriate, but we are intending to keep this a backward-compatible v1.x document. Given that maxRecords is used in client and inter-registry harvesting processes, changing this element could break a good deal of infrastructure. If we move to a version 2.0 of this document in the future, I would like to incorporate this change, but not in 1.1.

The extensionSearchSupport element is a deprecated tag from RI 1.0 intended to report whether the SOAP search capability of a searchable registry would handle only core VOResource elements or extension metadata, like capabilities. Since we are dropping the SOAP search capability but remaining a 1.x version document, it is deprecated but not removed. This can also be changed in 2.0.

-- TheresaDower - 2017-05-10

Okay, thanks Theresa. With the VOSI 1.1 change above I approve this document.

-- BrianMajor - 2017-05-10

Registry Working Group _(Markus Demleitner, Theresa Dower)

Registry, unsurprisingly, approves.

-- MarkusDemleitner - 2017-04-04

Semantics Working Group _(Mireille Louys, Alberto Accomazzi)

Education Interest Group _(Massimo Ramella, Sudhanshu Barway)

Time Domain Interest Group _(John Swinbank, Mike Fitzpatrick)

Data Curation & Preservation Interest Group (Francoise Genova)

Operations Interest Group _(Tom McGlynn, Mark Taylor)

Revision 142017-08-22 - FrancoisBonnarel

 
META TOPICPARENT name="IvoaResReg"

Registry Interfaces 1.1 Proposed Recommendation: Request for Comments

Public discusion page for the IVOA Registry Interfaces 1.1 Proposed Recommendation

The latest version of the RI 1.1 specification can be found at: http://www.ivoa.net/documents/RegistryInterface/20170201/

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Discussion about any of the comments or responses should be conducted on the registry mailing list, registry@ivoa.net . However, please be sure to enter your initial comments here for full consideration in any future revisions of this document.

Comments from the IVOA Community and TCG members during RFC period: 2017-02-07 - 2017-03-07

Comments from Mark Taylor

Document looks clear, and I support moving to a version that drops the SOAP-based client interfaces. I fixed some extremely minor typos in volute. One question (just curiosity really): what's the reason for introducing the new requirement for time granularity at the level of seconds that's mentioned in section 2.7? -- MarkTaylor - 2017-03-08

  • Without this requirement, a client has to retrieve an Identify response from a service to figure out what arguments it can pass. Everyone had implemented seconds granularity anyway, so it seemed reasonable to do away with one "free parameter". -- MarkusDemleitner - 2017-04-04


Comments from the TCG during the TCG Review Period

TCG Chair & Vice Chair _(Matthew Graham, Pat Dowler)

Applications Working Group _(Pierre Fernique, Tom Donaldson)

Two minor typos detected:

  • Page 10 "regiestries" -> registries
  • page 15 - "theListRecords" -> missing space after "the"
Apps approves this document. -- PierreFernique - 2017-05-10

Data Access Layer Working Group (Francois Bonnarel, Marco Molinaro)

Changed:
<
<
This document is actually really different from version 1.0. Some people may be lost. For newcomers, the introduction should clarify a bit immediatly that registry search was done by SOAP and that currently the unique standard method to query a registry is RegTAP.
>
>
This document is actually really different from version 1.0. Some people may be lost. For newcomers, the introduction should clarify a bit immediatly that registry search was done by SOAP and that currently the recommanded standard method to query a registry is RegTAP.
  The document sometimes quotes "version 1" and sometimes "version 1.0" or "specification 1.0" We recommand using "version 1.0" or "version 1.1" (when appropriate) everywhere. Appart from these two minor points we approve this document. -- FrancoisBonnarel - 2017-08-21 -- MarcoMolinaro - 2017-08-21

Data Model Working Group _(Mark Cresitello-Dittmar, Laurent Michel)

I have reviewed the 2017-04-03 version of the PR.

There is one typo that I noticed on pg 10, 'no' description has lost an 'a' in the break up of unavailable.. 'un-vailable'

DM approves this document. -- MarkCresitelloDittmar - 2017-05-11

Typo fixed in svn for the next build of the document; thank you. -- TheresaDower - 2017-05-16

Grid & Web Services Working Group (Brian Major, Giuliano Taffoni)

Since VOSI 1.1 is also near the end of RFC, could we update the reference to the 1.1 version instead of 1.0? It won't put any more burden on this spec than the 1.0 version does.

I think, in the capabilities example in Appendix C, it should be maxReturnRecords rather than maxRecords. (See: VOResource http://ivoa.net/documents/VOResource/20170425/PR-VOResource-1.1-20170425.html)

Also in the capabilities example: I'm not sure what the extensionSearchSupport element is... I see that it's in the SOAP based schema, but I don't see it in VOResource.

-- BrianMajor - 2017-05-03

I support the change to VOSI 1.1 since it won't affect existing implementations of this spec and will change it in the RI1.1 document text absent strong objections.

In the capabilities examples, "maxRecords" is the element in the vg:Registry extension as defined in v1.0 of Registry Interfaces. I agree from the VOResource spec that MaxReturnRecords would be more appropriate, but we are intending to keep this a backward-compatible v1.x document. Given that maxRecords is used in client and inter-registry harvesting processes, changing this element could break a good deal of infrastructure. If we move to a version 2.0 of this document in the future, I would like to incorporate this change, but not in 1.1.

The extensionSearchSupport element is a deprecated tag from RI 1.0 intended to report whether the SOAP search capability of a searchable registry would handle only core VOResource elements or extension metadata, like capabilities. Since we are dropping the SOAP search capability but remaining a 1.x version document, it is deprecated but not removed. This can also be changed in 2.0.

-- TheresaDower - 2017-05-10

Okay, thanks Theresa. With the VOSI 1.1 change above I approve this document.

-- BrianMajor - 2017-05-10

Registry Working Group _(Markus Demleitner, Theresa Dower)

Registry, unsurprisingly, approves.

-- MarkusDemleitner - 2017-04-04

Semantics Working Group _(Mireille Louys, Alberto Accomazzi)

Education Interest Group _(Massimo Ramella, Sudhanshu Barway)

Time Domain Interest Group _(John Swinbank, Mike Fitzpatrick)

Data Curation & Preservation Interest Group (Francoise Genova)

Operations Interest Group _(Tom McGlynn, Mark Taylor)

Revision 132017-08-21 - FrancoisBonnarel

 
META TOPICPARENT name="IvoaResReg"

Registry Interfaces 1.1 Proposed Recommendation: Request for Comments

Public discusion page for the IVOA Registry Interfaces 1.1 Proposed Recommendation

The latest version of the RI 1.1 specification can be found at: http://www.ivoa.net/documents/RegistryInterface/20170201/

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Discussion about any of the comments or responses should be conducted on the registry mailing list, registry@ivoa.net . However, please be sure to enter your initial comments here for full consideration in any future revisions of this document.

Comments from the IVOA Community and TCG members during RFC period: 2017-02-07 - 2017-03-07

Comments from Mark Taylor

Document looks clear, and I support moving to a version that drops the SOAP-based client interfaces. I fixed some extremely minor typos in volute. One question (just curiosity really): what's the reason for introducing the new requirement for time granularity at the level of seconds that's mentioned in section 2.7? -- MarkTaylor - 2017-03-08

  • Without this requirement, a client has to retrieve an Identify response from a service to figure out what arguments it can pass. Everyone had implemented seconds granularity anyway, so it seemed reasonable to do away with one "free parameter". -- MarkusDemleitner - 2017-04-04


Comments from the TCG during the TCG Review Period

TCG Chair & Vice Chair _(Matthew Graham, Pat Dowler)

Applications Working Group _(Pierre Fernique, Tom Donaldson)

Two minor typos detected:

  • Page 10 "regiestries" -> registries
  • page 15 - "theListRecords" -> missing space after "the"
Apps approves this document. -- PierreFernique - 2017-05-10

Data Access Layer Working Group (Francois Bonnarel, Marco Molinaro)

Added:
>
>
This document is actually really different from version 1.0. Some people may be lost. For newcomers, the introduction should clarify a bit immediatly that registry search was done by SOAP and that currently the unique standard method to query a registry is RegTAP. The document sometimes quotes "version 1" and sometimes "version 1.0" or "specification 1.0" We recommand using "version 1.0" or "version 1.1" (when appropriate) everywhere. Appart from these two minor points we approve this document. -- FrancoisBonnarel - 2017-08-21 -- MarcoMolinaro - 2017-08-21

 

Data Model Working Group _(Mark Cresitello-Dittmar, Laurent Michel)

I have reviewed the 2017-04-03 version of the PR.

There is one typo that I noticed on pg 10, 'no' description has lost an 'a' in the break up of unavailable.. 'un-vailable'

DM approves this document. -- MarkCresitelloDittmar - 2017-05-11

Typo fixed in svn for the next build of the document; thank you. -- TheresaDower - 2017-05-16

Grid & Web Services Working Group (Brian Major, Giuliano Taffoni)

Since VOSI 1.1 is also near the end of RFC, could we update the reference to the 1.1 version instead of 1.0? It won't put any more burden on this spec than the 1.0 version does.

I think, in the capabilities example in Appendix C, it should be maxReturnRecords rather than maxRecords. (See: VOResource http://ivoa.net/documents/VOResource/20170425/PR-VOResource-1.1-20170425.html)

Also in the capabilities example: I'm not sure what the extensionSearchSupport element is... I see that it's in the SOAP based schema, but I don't see it in VOResource.

-- BrianMajor - 2017-05-03

I support the change to VOSI 1.1 since it won't affect existing implementations of this spec and will change it in the RI1.1 document text absent strong objections.

In the capabilities examples, "maxRecords" is the element in the vg:Registry extension as defined in v1.0 of Registry Interfaces. I agree from the VOResource spec that MaxReturnRecords would be more appropriate, but we are intending to keep this a backward-compatible v1.x document. Given that maxRecords is used in client and inter-registry harvesting processes, changing this element could break a good deal of infrastructure. If we move to a version 2.0 of this document in the future, I would like to incorporate this change, but not in 1.1.

The extensionSearchSupport element is a deprecated tag from RI 1.0 intended to report whether the SOAP search capability of a searchable registry would handle only core VOResource elements or extension metadata, like capabilities. Since we are dropping the SOAP search capability but remaining a 1.x version document, it is deprecated but not removed. This can also be changed in 2.0.

-- TheresaDower - 2017-05-10

Okay, thanks Theresa. With the VOSI 1.1 change above I approve this document.

-- BrianMajor - 2017-05-10

Registry Working Group _(Markus Demleitner, Theresa Dower)

Registry, unsurprisingly, approves.

-- MarkusDemleitner - 2017-04-04

Semantics Working Group _(Mireille Louys, Alberto Accomazzi)

Education Interest Group _(Massimo Ramella, Sudhanshu Barway)

Time Domain Interest Group _(John Swinbank, Mike Fitzpatrick)

Data Curation & Preservation Interest Group (Francoise Genova)

Operations Interest Group _(Tom McGlynn, Mark Taylor)

Revision 122017-05-16 - TheresaDower

 
META TOPICPARENT name="IvoaResReg"

Registry Interfaces 1.1 Proposed Recommendation: Request for Comments

Public discusion page for the IVOA Registry Interfaces 1.1 Proposed Recommendation

The latest version of the RI 1.1 specification can be found at: http://www.ivoa.net/documents/RegistryInterface/20170201/

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Discussion about any of the comments or responses should be conducted on the registry mailing list, registry@ivoa.net . However, please be sure to enter your initial comments here for full consideration in any future revisions of this document.

Comments from the IVOA Community and TCG members during RFC period: 2017-02-07 - 2017-03-07

Comments from Mark Taylor

Document looks clear, and I support moving to a version that drops the SOAP-based client interfaces. I fixed some extremely minor typos in volute. One question (just curiosity really): what's the reason for introducing the new requirement for time granularity at the level of seconds that's mentioned in section 2.7? -- MarkTaylor - 2017-03-08

  • Without this requirement, a client has to retrieve an Identify response from a service to figure out what arguments it can pass. Everyone had implemented seconds granularity anyway, so it seemed reasonable to do away with one "free parameter". -- MarkusDemleitner - 2017-04-04


Comments from the TCG during the TCG Review Period

TCG Chair & Vice Chair _(Matthew Graham, Pat Dowler)

Applications Working Group _(Pierre Fernique, Tom Donaldson)

Two minor typos detected:

  • Page 10 "regiestries" -> registries
  • page 15 - "theListRecords" -> missing space after "the"
Apps approves this document. -- PierreFernique - 2017-05-10

Data Access Layer Working Group (Francois Bonnarel, Marco Molinaro)

Data Model Working Group _(Mark Cresitello-Dittmar, Laurent Michel)

I have reviewed the 2017-04-03 version of the PR.

There is one typo that I noticed on pg 10, 'no' description has lost an 'a' in the break up of unavailable.. 'un-vailable'

DM approves this document. -- MarkCresitelloDittmar - 2017-05-11

Added:
>
>
Typo fixed in svn for the next build of the document; thank you. -- TheresaDower - 2017-05-16
 

Grid & Web Services Working Group (Brian Major, Giuliano Taffoni)

Since VOSI 1.1 is also near the end of RFC, could we update the reference to the 1.1 version instead of 1.0? It won't put any more burden on this spec than the 1.0 version does.

I think, in the capabilities example in Appendix C, it should be maxReturnRecords rather than maxRecords. (See: VOResource http://ivoa.net/documents/VOResource/20170425/PR-VOResource-1.1-20170425.html)

Also in the capabilities example: I'm not sure what the extensionSearchSupport element is... I see that it's in the SOAP based schema, but I don't see it in VOResource.

-- BrianMajor - 2017-05-03

I support the change to VOSI 1.1 since it won't affect existing implementations of this spec and will change it in the RI1.1 document text absent strong objections.

In the capabilities examples, "maxRecords" is the element in the vg:Registry extension as defined in v1.0 of Registry Interfaces. I agree from the VOResource spec that MaxReturnRecords would be more appropriate, but we are intending to keep this a backward-compatible v1.x document. Given that maxRecords is used in client and inter-registry harvesting processes, changing this element could break a good deal of infrastructure. If we move to a version 2.0 of this document in the future, I would like to incorporate this change, but not in 1.1.

The extensionSearchSupport element is a deprecated tag from RI 1.0 intended to report whether the SOAP search capability of a searchable registry would handle only core VOResource elements or extension metadata, like capabilities. Since we are dropping the SOAP search capability but remaining a 1.x version document, it is deprecated but not removed. This can also be changed in 2.0.

-- TheresaDower - 2017-05-10

Okay, thanks Theresa. With the VOSI 1.1 change above I approve this document.

-- BrianMajor - 2017-05-10

Registry Working Group _(Markus Demleitner, Theresa Dower)

Registry, unsurprisingly, approves.

-- MarkusDemleitner - 2017-04-04

Semantics Working Group _(Mireille Louys, Alberto Accomazzi)

Education Interest Group _(Massimo Ramella, Sudhanshu Barway)

Time Domain Interest Group _(John Swinbank, Mike Fitzpatrick)

Data Curation & Preservation Interest Group (Francoise Genova)

Operations Interest Group _(Tom McGlynn, Mark Taylor)

Revision 112017-05-11 - MarkCresitelloDittmar

 
META TOPICPARENT name="IvoaResReg"

Registry Interfaces 1.1 Proposed Recommendation: Request for Comments

Public discusion page for the IVOA Registry Interfaces 1.1 Proposed Recommendation

The latest version of the RI 1.1 specification can be found at: http://www.ivoa.net/documents/RegistryInterface/20170201/

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Discussion about any of the comments or responses should be conducted on the registry mailing list, registry@ivoa.net . However, please be sure to enter your initial comments here for full consideration in any future revisions of this document.

Comments from the IVOA Community and TCG members during RFC period: 2017-02-07 - 2017-03-07

Comments from Mark Taylor

Document looks clear, and I support moving to a version that drops the SOAP-based client interfaces. I fixed some extremely minor typos in volute. One question (just curiosity really): what's the reason for introducing the new requirement for time granularity at the level of seconds that's mentioned in section 2.7? -- MarkTaylor - 2017-03-08

  • Without this requirement, a client has to retrieve an Identify response from a service to figure out what arguments it can pass. Everyone had implemented seconds granularity anyway, so it seemed reasonable to do away with one "free parameter". -- MarkusDemleitner - 2017-04-04


Comments from the TCG during the TCG Review Period

TCG Chair & Vice Chair _(Matthew Graham, Pat Dowler)

Applications Working Group _(Pierre Fernique, Tom Donaldson)

Two minor typos detected:

  • Page 10 "regiestries" -> registries
  • page 15 - "theListRecords" -> missing space after "the"
Apps approves this document. -- PierreFernique - 2017-05-10

Data Access Layer Working Group (Francois Bonnarel, Marco Molinaro)

Data Model Working Group _(Mark Cresitello-Dittmar, Laurent Michel)

Added:
>
>
I have reviewed the 2017-04-03 version of the PR.

There is one typo that I noticed on pg 10, 'no' description has lost an 'a' in the break up of unavailable.. 'un-vailable'

DM approves this document. -- MarkCresitelloDittmar - 2017-05-11

 

Grid & Web Services Working Group (Brian Major, Giuliano Taffoni)

Since VOSI 1.1 is also near the end of RFC, could we update the reference to the 1.1 version instead of 1.0? It won't put any more burden on this spec than the 1.0 version does.

I think, in the capabilities example in Appendix C, it should be maxReturnRecords rather than maxRecords. (See: VOResource http://ivoa.net/documents/VOResource/20170425/PR-VOResource-1.1-20170425.html)

Also in the capabilities example: I'm not sure what the extensionSearchSupport element is... I see that it's in the SOAP based schema, but I don't see it in VOResource.

-- BrianMajor - 2017-05-03

I support the change to VOSI 1.1 since it won't affect existing implementations of this spec and will change it in the RI1.1 document text absent strong objections.

In the capabilities examples, "maxRecords" is the element in the vg:Registry extension as defined in v1.0 of Registry Interfaces. I agree from the VOResource spec that MaxReturnRecords would be more appropriate, but we are intending to keep this a backward-compatible v1.x document. Given that maxRecords is used in client and inter-registry harvesting processes, changing this element could break a good deal of infrastructure. If we move to a version 2.0 of this document in the future, I would like to incorporate this change, but not in 1.1.

The extensionSearchSupport element is a deprecated tag from RI 1.0 intended to report whether the SOAP search capability of a searchable registry would handle only core VOResource elements or extension metadata, like capabilities. Since we are dropping the SOAP search capability but remaining a 1.x version document, it is deprecated but not removed. This can also be changed in 2.0.

-- TheresaDower - 2017-05-10

Okay, thanks Theresa. With the VOSI 1.1 change above I approve this document.

-- BrianMajor - 2017-05-10

Registry Working Group _(Markus Demleitner, Theresa Dower)

Registry, unsurprisingly, approves.

-- MarkusDemleitner - 2017-04-04

Semantics Working Group _(Mireille Louys, Alberto Accomazzi)

Education Interest Group _(Massimo Ramella, Sudhanshu Barway)

Time Domain Interest Group _(John Swinbank, Mike Fitzpatrick)

Data Curation & Preservation Interest Group (Francoise Genova)

Operations Interest Group _(Tom McGlynn, Mark Taylor)

Revision 102017-05-10 - PierreFernique

 
META TOPICPARENT name="IvoaResReg"

Registry Interfaces 1.1 Proposed Recommendation: Request for Comments

Public discusion page for the IVOA Registry Interfaces 1.1 Proposed Recommendation

The latest version of the RI 1.1 specification can be found at: http://www.ivoa.net/documents/RegistryInterface/20170201/

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Discussion about any of the comments or responses should be conducted on the registry mailing list, registry@ivoa.net . However, please be sure to enter your initial comments here for full consideration in any future revisions of this document.

Comments from the IVOA Community and TCG members during RFC period: 2017-02-07 - 2017-03-07

Comments from Mark Taylor

Document looks clear, and I support moving to a version that drops the SOAP-based client interfaces. I fixed some extremely minor typos in volute. One question (just curiosity really): what's the reason for introducing the new requirement for time granularity at the level of seconds that's mentioned in section 2.7? -- MarkTaylor - 2017-03-08

  • Without this requirement, a client has to retrieve an Identify response from a service to figure out what arguments it can pass. Everyone had implemented seconds granularity anyway, so it seemed reasonable to do away with one "free parameter". -- MarkusDemleitner - 2017-04-04


Comments from the TCG during the TCG Review Period

TCG Chair & Vice Chair _(Matthew Graham, Pat Dowler)

Applications Working Group _(Pierre Fernique, Tom Donaldson)

Added:
>
>
Two minor typos detected:
  • Page 10 "regiestries" -> registries
  • page 15 - "theListRecords" -> missing space after "the"
Apps approves this document. -- PierreFernique - 2017-05-10
 

Data Access Layer Working Group (Francois Bonnarel, Marco Molinaro)

Data Model Working Group _(Mark Cresitello-Dittmar, Laurent Michel)

Grid & Web Services Working Group (Brian Major, Giuliano Taffoni)

Since VOSI 1.1 is also near the end of RFC, could we update the reference to the 1.1 version instead of 1.0? It won't put any more burden on this spec than the 1.0 version does.

I think, in the capabilities example in Appendix C, it should be maxReturnRecords rather than maxRecords. (See: VOResource http://ivoa.net/documents/VOResource/20170425/PR-VOResource-1.1-20170425.html)

Also in the capabilities example: I'm not sure what the extensionSearchSupport element is... I see that it's in the SOAP based schema, but I don't see it in VOResource.

-- BrianMajor - 2017-05-03

I support the change to VOSI 1.1 since it won't affect existing implementations of this spec and will change it in the RI1.1 document text absent strong objections.

In the capabilities examples, "maxRecords" is the element in the vg:Registry extension as defined in v1.0 of Registry Interfaces. I agree from the VOResource spec that MaxReturnRecords would be more appropriate, but we are intending to keep this a backward-compatible v1.x document. Given that maxRecords is used in client and inter-registry harvesting processes, changing this element could break a good deal of infrastructure. If we move to a version 2.0 of this document in the future, I would like to incorporate this change, but not in 1.1.

The extensionSearchSupport element is a deprecated tag from RI 1.0 intended to report whether the SOAP search capability of a searchable registry would handle only core VOResource elements or extension metadata, like capabilities. Since we are dropping the SOAP search capability but remaining a 1.x version document, it is deprecated but not removed. This can also be changed in 2.0.

-- TheresaDower - 2017-05-10

Okay, thanks Theresa. With the VOSI 1.1 change above I approve this document.

-- BrianMajor - 2017-05-10

Registry Working Group _(Markus Demleitner, Theresa Dower)

Registry, unsurprisingly, approves.

-- MarkusDemleitner - 2017-04-04

Semantics Working Group _(Mireille Louys, Alberto Accomazzi)

Education Interest Group _(Massimo Ramella, Sudhanshu Barway)

Time Domain Interest Group _(John Swinbank, Mike Fitzpatrick)

Data Curation & Preservation Interest Group (Francoise Genova)

Operations Interest Group _(Tom McGlynn, Mark Taylor)

Revision 92017-05-10 - BrianMajor

 
META TOPICPARENT name="IvoaResReg"

Registry Interfaces 1.1 Proposed Recommendation: Request for Comments

Public discusion page for the IVOA Registry Interfaces 1.1 Proposed Recommendation

The latest version of the RI 1.1 specification can be found at: http://www.ivoa.net/documents/RegistryInterface/20170201/

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Discussion about any of the comments or responses should be conducted on the registry mailing list, registry@ivoa.net . However, please be sure to enter your initial comments here for full consideration in any future revisions of this document.

Comments from the IVOA Community and TCG members during RFC period: 2017-02-07 - 2017-03-07

Comments from Mark Taylor

Document looks clear, and I support moving to a version that drops the SOAP-based client interfaces. I fixed some extremely minor typos in volute. One question (just curiosity really): what's the reason for introducing the new requirement for time granularity at the level of seconds that's mentioned in section 2.7? -- MarkTaylor - 2017-03-08

  • Without this requirement, a client has to retrieve an Identify response from a service to figure out what arguments it can pass. Everyone had implemented seconds granularity anyway, so it seemed reasonable to do away with one "free parameter". -- MarkusDemleitner - 2017-04-04


Comments from the TCG during the TCG Review Period

TCG Chair & Vice Chair _(Matthew Graham, Pat Dowler)

Applications Working Group _(Pierre Fernique, Tom Donaldson)

Data Access Layer Working Group (Francois Bonnarel, Marco Molinaro)

Data Model Working Group _(Mark Cresitello-Dittmar, Laurent Michel)

Grid & Web Services Working Group (Brian Major, Giuliano Taffoni)

Since VOSI 1.1 is also near the end of RFC, could we update the reference to the 1.1 version instead of 1.0? It won't put any more burden on this spec than the 1.0 version does.

I think, in the capabilities example in Appendix C, it should be maxReturnRecords rather than maxRecords. (See: VOResource http://ivoa.net/documents/VOResource/20170425/PR-VOResource-1.1-20170425.html)

Also in the capabilities example: I'm not sure what the extensionSearchSupport element is... I see that it's in the SOAP based schema, but I don't see it in VOResource.

-- BrianMajor - 2017-05-03

I support the change to VOSI 1.1 since it won't affect existing implementations of this spec and will change it in the RI1.1 document text absent strong objections.

In the capabilities examples, "maxRecords" is the element in the vg:Registry extension as defined in v1.0 of Registry Interfaces. I agree from the VOResource spec that MaxReturnRecords would be more appropriate, but we are intending to keep this a backward-compatible v1.x document. Given that maxRecords is used in client and inter-registry harvesting processes, changing this element could break a good deal of infrastructure. If we move to a version 2.0 of this document in the future, I would like to incorporate this change, but not in 1.1.

The extensionSearchSupport element is a deprecated tag from RI 1.0 intended to report whether the SOAP search capability of a searchable registry would handle only core VOResource elements or extension metadata, like capabilities. Since we are dropping the SOAP search capability but remaining a 1.x version document, it is deprecated but not removed. This can also be changed in 2.0.

-- TheresaDower - 2017-05-10

Added:
>
>
Okay, thanks Theresa. With the VOSI 1.1 change above I approve this document.

-- BrianMajor - 2017-05-10

 

Registry Working Group _(Markus Demleitner, Theresa Dower)

Registry, unsurprisingly, approves.

-- MarkusDemleitner - 2017-04-04

Semantics Working Group _(Mireille Louys, Alberto Accomazzi)

Education Interest Group _(Massimo Ramella, Sudhanshu Barway)

Time Domain Interest Group _(John Swinbank, Mike Fitzpatrick)

Data Curation & Preservation Interest Group (Francoise Genova)

Operations Interest Group _(Tom McGlynn, Mark Taylor)

Revision 82017-05-10 - TheresaDower

 
META TOPICPARENT name="IvoaResReg"

Registry Interfaces 1.1 Proposed Recommendation: Request for Comments

Public discusion page for the IVOA Registry Interfaces 1.1 Proposed Recommendation

The latest version of the RI 1.1 specification can be found at: http://www.ivoa.net/documents/RegistryInterface/20170201/

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Discussion about any of the comments or responses should be conducted on the registry mailing list, registry@ivoa.net . However, please be sure to enter your initial comments here for full consideration in any future revisions of this document.

Comments from the IVOA Community and TCG members during RFC period: 2017-02-07 - 2017-03-07

Comments from Mark Taylor

Document looks clear, and I support moving to a version that drops the SOAP-based client interfaces. I fixed some extremely minor typos in volute. One question (just curiosity really): what's the reason for introducing the new requirement for time granularity at the level of seconds that's mentioned in section 2.7? -- MarkTaylor - 2017-03-08

  • Without this requirement, a client has to retrieve an Identify response from a service to figure out what arguments it can pass. Everyone had implemented seconds granularity anyway, so it seemed reasonable to do away with one "free parameter". -- MarkusDemleitner - 2017-04-04


Comments from the TCG during the TCG Review Period

TCG Chair & Vice Chair _(Matthew Graham, Pat Dowler)

Applications Working Group _(Pierre Fernique, Tom Donaldson)

Data Access Layer Working Group (Francois Bonnarel, Marco Molinaro)

Data Model Working Group _(Mark Cresitello-Dittmar, Laurent Michel)

Grid & Web Services Working Group (Brian Major, Giuliano Taffoni)

Since VOSI 1.1 is also near the end of RFC, could we update the reference to the 1.1 version instead of 1.0? It won't put any more burden on this spec than the 1.0 version does.

I think, in the capabilities example in Appendix C, it should be maxReturnRecords rather than maxRecords. (See: VOResource http://ivoa.net/documents/VOResource/20170425/PR-VOResource-1.1-20170425.html)

Also in the capabilities example: I'm not sure what the extensionSearchSupport element is... I see that it's in the SOAP based schema, but I don't see it in VOResource.

-- BrianMajor - 2017-05-03

Added:
>
>
I support the change to VOSI 1.1 since it won't affect existing implementations of this spec and will change it in the RI1.1 document text absent strong objections.

In the capabilities examples, "maxRecords" is the element in the vg:Registry extension as defined in v1.0 of Registry Interfaces. I agree from the VOResource spec that MaxReturnRecords would be more appropriate, but we are intending to keep this a backward-compatible v1.x document. Given that maxRecords is used in client and inter-registry harvesting processes, changing this element could break a good deal of infrastructure. If we move to a version 2.0 of this document in the future, I would like to incorporate this change, but not in 1.1.

The extensionSearchSupport element is a deprecated tag from RI 1.0 intended to report whether the SOAP search capability of a searchable registry would handle only core VOResource elements or extension metadata, like capabilities. Since we are dropping the SOAP search capability but remaining a 1.x version document, it is deprecated but not removed. This can also be changed in 2.0.

-- TheresaDower - 2017-05-10

 

Registry Working Group _(Markus Demleitner, Theresa Dower)

Registry, unsurprisingly, approves.

-- MarkusDemleitner - 2017-04-04

Semantics Working Group _(Mireille Louys, Alberto Accomazzi)

Education Interest Group _(Massimo Ramella, Sudhanshu Barway)

Time Domain Interest Group _(John Swinbank, Mike Fitzpatrick)

Data Curation & Preservation Interest Group (Francoise Genova)

Operations Interest Group _(Tom McGlynn, Mark Taylor)

Revision 72017-05-03 - BrianMajor

 
META TOPICPARENT name="IvoaResReg"

Registry Interfaces 1.1 Proposed Recommendation: Request for Comments

Public discusion page for the IVOA Registry Interfaces 1.1 Proposed Recommendation

The latest version of the RI 1.1 specification can be found at: http://www.ivoa.net/documents/RegistryInterface/20170201/

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Discussion about any of the comments or responses should be conducted on the registry mailing list, registry@ivoa.net . However, please be sure to enter your initial comments here for full consideration in any future revisions of this document.

Comments from the IVOA Community and TCG members during RFC period: 2017-02-07 - 2017-03-07

Comments from Mark Taylor

Document looks clear, and I support moving to a version that drops the SOAP-based client interfaces. I fixed some extremely minor typos in volute. One question (just curiosity really): what's the reason for introducing the new requirement for time granularity at the level of seconds that's mentioned in section 2.7? -- MarkTaylor - 2017-03-08

  • Without this requirement, a client has to retrieve an Identify response from a service to figure out what arguments it can pass. Everyone had implemented seconds granularity anyway, so it seemed reasonable to do away with one "free parameter". -- MarkusDemleitner - 2017-04-04


Comments from the TCG during the TCG Review Period

TCG Chair & Vice Chair _(Matthew Graham, Pat Dowler)

Applications Working Group _(Pierre Fernique, Tom Donaldson)

Data Access Layer Working Group (Francois Bonnarel, Marco Molinaro)

Data Model Working Group _(Mark Cresitello-Dittmar, Laurent Michel)

Grid & Web Services Working Group (Brian Major, Giuliano Taffoni)

Added:
>
>
Since VOSI 1.1 is also near the end of RFC, could we update the reference to the 1.1 version instead of 1.0? It won't put any more burden on this spec than the 1.0 version does.

I think, in the capabilities example in Appendix C, it should be maxReturnRecords rather than maxRecords. (See: VOResource http://ivoa.net/documents/VOResource/20170425/PR-VOResource-1.1-20170425.html)

Also in the capabilities example: I'm not sure what the extensionSearchSupport element is... I see that it's in the SOAP based schema, but I don't see it in VOResource.

-- BrianMajor - 2017-05-03

 

Registry Working Group _(Markus Demleitner, Theresa Dower)

Registry, unsurprisingly, approves.

-- MarkusDemleitner - 2017-04-04

Semantics Working Group _(Mireille Louys, Alberto Accomazzi)

Education Interest Group _(Massimo Ramella, Sudhanshu Barway)

Time Domain Interest Group _(John Swinbank, Mike Fitzpatrick)

Data Curation & Preservation Interest Group (Francoise Genova)

Operations Interest Group _(Tom McGlynn, Mark Taylor)

Revision 62017-04-24 - TheresaDower

 
META TOPICPARENT name="IvoaResReg"

Registry Interfaces 1.1 Proposed Recommendation: Request for Comments

Public discusion page for the IVOA Registry Interfaces 1.1 Proposed Recommendation

The latest version of the RI 1.1 specification can be found at: http://www.ivoa.net/documents/RegistryInterface/20170201/

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Discussion about any of the comments or responses should be conducted on the registry mailing list, registry@ivoa.net . However, please be sure to enter your initial comments here for full consideration in any future revisions of this document.

Comments from the IVOA Community and TCG members during RFC period: 2017-02-07 - 2017-03-07

Comments from Mark Taylor

Document looks clear, and I support moving to a version that drops the SOAP-based client interfaces. I fixed some extremely minor typos in volute. One question (just curiosity really): what's the reason for introducing the new requirement for time granularity at the level of seconds that's mentioned in section 2.7? -- MarkTaylor - 2017-03-08

  • Without this requirement, a client has to retrieve an Identify response from a service to figure out what arguments it can pass. Everyone had implemented seconds granularity anyway, so it seemed reasonable to do away with one "free parameter". -- MarkusDemleitner - 2017-04-04


Comments from the TCG during the TCG Review Period

Changed:
<
<

TCG Chair & Vice Chair

Applications Working Group

Data Access Layer Working Group

Data Model Working Group

Grid & Web Services Working Group

Registry Working Group

>
>

TCG Chair & Vice Chair _(Matthew Graham, Pat Dowler)

Applications Working Group _(Pierre Fernique, Tom Donaldson)

Data Access Layer Working Group (Francois Bonnarel, Marco Molinaro)

Data Model Working Group _(Mark Cresitello-Dittmar, Laurent Michel)

Grid & Web Services Working Group (Brian Major, Giuliano Taffoni)

Registry Working Group _(Markus Demleitner, Theresa Dower)

  Registry, unsurprisingly, approves.

-- MarkusDemleitner - 2017-04-04

Changed:
<
<

Semantics Working Group

Education Interest Group

Time Domain Interest Group

Data Curation & Preservation Interest Group

Operations Interest Group

>
>

Semantics Working Group _(Mireille Louys, Alberto Accomazzi)

Education Interest Group _(Massimo Ramella, Sudhanshu Barway)

Time Domain Interest Group _(John Swinbank, Mike Fitzpatrick)

Data Curation & Preservation Interest Group (Francoise Genova)

Operations Interest Group _(Tom McGlynn, Mark Taylor)

 

Revision 52017-04-04 - MarkusDemleitner

 
META TOPICPARENT name="IvoaResReg"

Registry Interfaces 1.1 Proposed Recommendation: Request for Comments

Public discusion page for the IVOA Registry Interfaces 1.1 Proposed Recommendation

The latest version of the RI 1.1 specification can be found at: http://www.ivoa.net/documents/RegistryInterface/20170201/

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Discussion about any of the comments or responses should be conducted on the registry mailing list, registry@ivoa.net . However, please be sure to enter your initial comments here for full consideration in any future revisions of this document.

Comments from the IVOA Community and TCG members during RFC period: 2017-02-07 - 2017-03-07

Comments from Mark Taylor

Deleted:
<
<
Document looks clear, and I support moving to a version that drops the SOAP-based client interfaces. I fixed some extremely minor typos in volute. One question (just curiosity really): what's the reason for introducing the new requirement for time granularity at the level of seconds that's mentioned in section 2.7? -- MarkTaylor - 2017-03-08
 
Added:
>
>
Document looks clear, and I support moving to a version that drops the SOAP-based client interfaces. I fixed some extremely minor typos in volute. One question (just curiosity really): what's the reason for introducing the new requirement for time granularity at the level of seconds that's mentioned in section 2.7? -- MarkTaylor - 2017-03-08

  • Without this requirement, a client has to retrieve an Identify response from a service to figure out what arguments it can pass. Everyone had implemented seconds granularity anyway, so it seemed reasonable to do away with one "free parameter". -- MarkusDemleitner - 2017-04-04
 


Comments from the TCG during the TCG Review Period

TCG Chair & Vice Chair

Applications Working Group

Data Access Layer Working Group

Data Model Working Group

Grid & Web Services Working Group

Registry Working Group

Added:
>
>
Registry, unsurprisingly, approves.

-- MarkusDemleitner - 2017-04-04

 

Semantics Working Group

Education Interest Group

Time Domain Interest Group

Data Curation & Preservation Interest Group

Operations Interest Group

Revision 42017-03-08 - MarkTaylor

 
META TOPICPARENT name="IvoaResReg"

Registry Interfaces 1.1 Proposed Recommendation: Request for Comments

Public discusion page for the IVOA Registry Interfaces 1.1 Proposed Recommendation

The latest version of the RI 1.1 specification can be found at: http://www.ivoa.net/documents/RegistryInterface/20170201/

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Discussion about any of the comments or responses should be conducted on the registry mailing list, registry@ivoa.net . However, please be sure to enter your initial comments here for full consideration in any future revisions of this document.

Comments from the IVOA Community and TCG members during RFC period: 2017-02-07 - 2017-03-07

Added:
>
>

Comments from Mark Taylor

Document looks clear, and I support moving to a version that drops the SOAP-based client interfaces. I fixed some extremely minor typos in volute. One question (just curiosity really): what's the reason for introducing the new requirement for time granularity at the level of seconds that's mentioned in section 2.7? -- MarkTaylor - 2017-03-08
 


Comments from the TCG during the TCG Review Period

TCG Chair & Vice Chair

Applications Working Group

Data Access Layer Working Group

Data Model Working Group

Grid & Web Services Working Group

Registry Working Group

Semantics Working Group

Education Interest Group

Time Domain Interest Group

Data Curation & Preservation Interest Group

Operations Interest Group

Revision 32017-02-07 - TheresaDower

 
META TOPICPARENT name="IvoaResReg"

Registry Interfaces 1.1 Proposed Recommendation: Request for Comments

Public discusion page for the IVOA Registry Interfaces 1.1 Proposed Recommendation

The latest version of the RI 1.1 specification can be found at: http://www.ivoa.net/documents/RegistryInterface/20170201/

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Discussion about any of the comments or responses should be conducted on the registry mailing list, registry@ivoa.net . However, please be sure to enter your initial comments here for full consideration in any future revisions of this document.

Comments from the IVOA Community and TCG members during RFC period: 2017-02-07 - 2017-03-07


Comments from the TCG during the TCG Review Period

TCG Chair & Vice Chair

Applications Working Group

Data Access Layer Working Group

Data Model Working Group

Grid & Web Services Working Group

Registry Working Group

Semantics Working Group

Education Interest Group

Time Domain Interest Group

Data Curation & Preservation Interest Group

Operations Interest Group

Deleted:
<
<
<!--

-->
 

Revision 22017-02-06 - TheresaDower

 
META TOPICPARENT name="IvoaResReg"

Registry Interfaces 1.1 Proposed Recommendation: Request for Comments

Public discusion page for the IVOA Registry Interfaces 1.1 Proposed Recommendation

The latest version of the RI 1.1 specification can be found at: http://www.ivoa.net/documents/RegistryInterface/20170201/

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Changed:
<
<
Discussion about any of the comments or responses should be conducted on the registry mailing list, registry@ivoa.net . However, please be sure to enter your initial comments here for full consideration in any future revisions of this document.
>
>
Discussion about any of the comments or responses should be conducted on the registry mailing list, registry@ivoa.net . However, please be sure to enter your initial comments here for full consideration in any future revisions of this document.
 
Changed:
<
<

Comments from the IVOA Community and TCG members during RFC period: 2017-02-03 - 2017-03-03

>
>

Comments from the IVOA Community and TCG members during RFC period: 2017-02-07 - 2017-03-07

 


Comments from the TCG during the TCG Review Period

TCG Chair & Vice Chair

Applications Working Group

Data Access Layer Working Group

Data Model Working Group

Grid & Web Services Working Group

Registry Working Group

Semantics Working Group

Education Interest Group

Time Domain Interest Group

Data Curation & Preservation Interest Group

Operations Interest Group

<!--
Added:
>
>
 
Changed:
<
<
-->
>
>
-->
 

Revision 12017-02-02 - TheresaDower

 
META TOPICPARENT name="IvoaResReg"

Registry Interfaces 1.1 Proposed Recommendation: Request for Comments

Public discusion page for the IVOA Registry Interfaces 1.1 Proposed Recommendation

The latest version of the RI 1.1 specification can be found at: http://www.ivoa.net/documents/RegistryInterface/20170201/

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Discussion about any of the comments or responses should be conducted on the registry mailing list, registry@ivoa.net . However, please be sure to enter your initial comments here for full consideration in any future revisions of this document.

Comments from the IVOA Community and TCG members during RFC period: 2017-02-03 - 2017-03-03


Comments from the TCG during the TCG Review Period

TCG Chair & Vice Chair

Applications Working Group

Data Access Layer Working Group

Data Model Working Group

Grid & Web Services Working Group

Registry Working Group

Semantics Working Group

Education Interest Group

Time Domain Interest Group

Data Curation & Preservation Interest Group

Operations Interest Group

<!--

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