Request for Comment: SimpleDALRegExt v1.0This document serves as the RFC center for the Proposed Recommendation entitled "Describing Simple Data Access Services, Version 1.0". The version reviewed during the RFC can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20120517/. The version revised for TCG Review can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20121116/. RFC Review period: May 23, 2012 - June 27, 2012 CompletedTCG Review period: 4 Dec 2012 - 4 Jan 2013 Exec Approved for REC: Attention TCG: if you prefer printing out a PDF version for review, consider this abbreviated version. It omits the inclusion of the appendices listing the full XML schemas, resulting in 50% fewer pages.To add a comment on 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 that 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. Additional discussion about any of the comments or responses can be conducted on the Resource 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 Notes on Implementations and ValidatersThe SimpleDALRegExt page includes several compliant sample VOResource instances that use the extension schemas defined in the spec.. Instances can be validated with an XML Schema validater such as the one provided with Junx (which is based on Xerxes). Previous versions of the extensions for ConeSearch, SIA, and SSA, which the PR versions are backward-compatible with, have been in production use by IVOA-compliant registries for several years.Comments from the communityComments from MarkTaylorA couple of comments about the schema:
Comments from TheresaDower(pardon any major formatting issues; twiki is not being kind to my preview/editing attempts) I will admit I am unsure how much this document is supposed to be an administrative collation of the existing standards and how much we intend to change each of them with an eye on backward compatibility. This may or may not be the stage at which to address inconsistencies between the standards, but I can't think of a better one. (It may also be well past time, as I note we've already gone over the RFC date but are requesting more feedback.)
Comments from Randy ThompsonComments and questions (as sent to Ray last month) * General:
"The sky coordinate axes may not particularly parallel with the image axes (e.g. due to rotation or projection effects); in this case, the longitudinal side should be considered the side of the image that it cuts the smallest angle with."Why not just define maxImageSize as the x,y dimensions in pixels of the largest image that can be requested? I suspect this is what most data providers do anyway.
"A VOResource resource description must not include both a ssap:SimpleSpectralAccess capability and a ssap:ProtoSpectralAccess capability that describe the same service base URL, as given by the <interface>'S<accessURL>."I'm not sure what "<interface>'S<accessURL>"means, but does this sentence imply our services are no longer allowed?
Comments from TCG members during the TCG Review Period: 04/Dec/2012 – 04/Jan/2013WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham ) | ||||||||
Added: | ||||||||
> > | Approved -- SeverinGaudet - 2013-09-19 | |||||||
Applications Working Group ( _Mark Taylor, Pierre Fernique )Looks good, just a few errors/queries, mostly in section 3.3.2:
Data Access Layer Working Group ( Patrick Dowler, Mike Fitzpatrick )1. Is there a way to specify allowed enumerated values in a capability custom <param> element? Specifically, if a service has some custom params with a small number of allowed values, this can say be expressed in the VOTable metadata response. Is that the only way or can they also put it in the registry record? 2. For SIA services, the maxImageExtent and skySize should specify units are in degrees. 3. Why is there no 'complianceLevel' for SIA? At least minimal/full values that say whether the 'should' is implemented or not. 4. Under SSA, 'maxFileSize' says "maximum image size" in the semantic meaning Comment: I was able to implement VOSICapabilities for the CADC SIA service using this spec; the only problem was finding the schema file (at the time) so I could perform validation. http://www.cadc.hia.nrc.gc.ca/sia/capabilities Clarification or explanation to improve the document is a sufficient response. Approved From RayPlante:
Data Model Working Group ( _Jesus Salgado, Omar Laurino )Approved Some small comments (with response from RayPlante): Introduction: typo -> whereever (RayPlante: thanks) Section 2: This is not probably applicable to this document (more to DataService) but, in order to substitute the current SSAP approach for theoretical services with a VOResource approach, ParamHTTP (BaseParam) should allow for min/max values and vocabulary restrictions on the values (the idea behind TSAP and S3 is to allow the creation of an input form on the fly). Is this possible? | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Deleted: | ||||||||
< < | OK. We will take note of this as a possible enhacement of a future updated version of VODataService, then -- JesusSalgado - 2013-09-12 | |||||||
Added: | ||||||||
> > | OK. We will take note of this as a possible enhacement of a future updated version of VODataService, then -- JesusSalgado - 2013-09-12 | |||||||
3.2.2.1 SkySize: In general, the allowed values are not to clear for some types. For example, SkySize seems to be in degrees but we only can know it by reading the help (as far as I know). It could be useful to allow for element restrictions (minInclussive, maxInclussive) that would help the validation. This is applicable to many other types like, e.g. SkyPos | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Deleted: | ||||||||
< < | I note that we explicitly state in the VOResource spec that the schema is not the sole standard of validity and that validaters need to go beyond the schema to fully validate a resource record. This choice was made explicitly to help cut down on complexity within the schema documents. I understand the risk so we can pass on this for this version -- JesusSalgado - 2013-09-12 | |||||||
Added: | ||||||||
> > | I understand the risk so we can pass on this for this version -- JesusSalgado - 2013-09-12 | |||||||
Appendix: There are references to some xml namespaces not present in the location (like
http://www.ivoa.net/xml/VOMetadata/v0.1It would be good to correct this in order to ensure a proper parsing. | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Deleted: | ||||||||
< < | | |||||||
A draft with corrections can be found on the SimpleDALRegExt page.
-- JesusSalgado - 2013-06-10
Grid & Web Services Working Group ( Andreas Wicenec, Andre Schaaff )Nothing to add to the already existing comments. Go ahead.Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner)
Semantics Working Group ( _Norman Gray, Mireille Louys)The Semantics WG approves this document. Sub-editing: p2, The expansion of the 'XML' acronym appears, from the XML standard, to be "Extensible Markup Language", not "eXtensible Markup Language" From RayPlante: so corrected (see pending draft).Data Curation & Preservation Interest Group ( Alberto Accomazzi, Françoise Genova )Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Knowledge Discovery in Databases Interest Group ( George Djorgovski )Theory Interest Group ( _Franck Le Petit, Rick Wagner )Time Domain Interest Group ( _Matthew Graham, John Swinbank )I approve this document. -- MatthewGraham - 2013-05-01Standards and Processes Committee ( Françoise Genova )<--
|
Request for Comment: SimpleDALRegExt v1.0This document serves as the RFC center for the Proposed Recommendation entitled "Describing Simple Data Access Services, Version 1.0". The version reviewed during the RFC can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20120517/. The version revised for TCG Review can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20121116/. RFC Review period: May 23, 2012 - June 27, 2012 CompletedTCG Review period: 4 Dec 2012 - 4 Jan 2013 Exec Approved for REC: Attention TCG: if you prefer printing out a PDF version for review, consider this abbreviated version. It omits the inclusion of the appendices listing the full XML schemas, resulting in 50% fewer pages.To add a comment on 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 that 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. Additional discussion about any of the comments or responses can be conducted on the Resource 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 Notes on Implementations and ValidatersThe SimpleDALRegExt page includes several compliant sample VOResource instances that use the extension schemas defined in the spec.. Instances can be validated with an XML Schema validater such as the one provided with Junx (which is based on Xerxes). Previous versions of the extensions for ConeSearch, SIA, and SSA, which the PR versions are backward-compatible with, have been in production use by IVOA-compliant registries for several years.Comments from the communityComments from MarkTaylorA couple of comments about the schema:
Comments from TheresaDower(pardon any major formatting issues; twiki is not being kind to my preview/editing attempts) I will admit I am unsure how much this document is supposed to be an administrative collation of the existing standards and how much we intend to change each of them with an eye on backward compatibility. This may or may not be the stage at which to address inconsistencies between the standards, but I can't think of a better one. (It may also be well past time, as I note we've already gone over the RFC date but are requesting more feedback.)
Comments from Randy ThompsonComments and questions (as sent to Ray last month) * General:
"The sky coordinate axes may not particularly parallel with the image axes (e.g. due to rotation or projection effects); in this case, the longitudinal side should be considered the side of the image that it cuts the smallest angle with."Why not just define maxImageSize as the x,y dimensions in pixels of the largest image that can be requested? I suspect this is what most data providers do anyway.
"A VOResource resource description must not include both a ssap:SimpleSpectralAccess capability and a ssap:ProtoSpectralAccess capability that describe the same service base URL, as given by the <interface>'S<accessURL>."I'm not sure what "<interface>'S<accessURL>"means, but does this sentence imply our services are no longer allowed?
Comments from TCG members during the TCG Review Period: 04/Dec/2012 – 04/Jan/2013WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham )Applications Working Group ( _Mark Taylor, Pierre Fernique )Looks good, just a few errors/queries, mostly in section 3.3.2:
Data Access Layer Working Group ( Patrick Dowler, Mike Fitzpatrick )1. Is there a way to specify allowed enumerated values in a capability custom <param> element? Specifically, if a service has some custom params with a small number of allowed values, this can say be expressed in the VOTable metadata response. Is that the only way or can they also put it in the registry record? 2. For SIA services, the maxImageExtent and skySize should specify units are in degrees. 3. Why is there no 'complianceLevel' for SIA? At least minimal/full values that say whether the 'should' is implemented or not. 4. Under SSA, 'maxFileSize' says "maximum image size" in the semantic meaning Comment: I was able to implement VOSICapabilities for the CADC SIA service using this spec; the only problem was finding the schema file (at the time) so I could perform validation. http://www.cadc.hia.nrc.gc.ca/sia/capabilities Clarification or explanation to improve the document is a sufficient response. Approved | ||||||||
Changed: | ||||||||
< < | From RayPlante: | |||||||
> > | From RayPlante: | |||||||
Deleted: | ||||||||
< < |
| |||||||
Changed: | ||||||||
< < | A draft with these corrections can be found on the SimpleDALRegExt page. | |||||||
> > |
| |||||||
Added: | ||||||||
> > |
| |||||||
Added: | ||||||||
> > | A draft with these corrections can be found on the SimpleDALRegExt page. | |||||||
-- PatrickDowler - 2013-05-17
Data Model Working Group ( _Jesus Salgado, Omar Laurino )Approved Some small comments (with response from RayPlante): | ||||||||
Changed: | ||||||||
< < | Introduction: typo -> whereever (RayPlante: thanks) | |||||||
> > | Introduction: typo -> whereever (RayPlante: thanks) | |||||||
Changed: | ||||||||
< < | Section 2: This is not probably applicable to this document (more to DataService) but, in order to substitute the current SSAP approach for theoretical services with a VOResource approach, ParamHTTP (BaseParam) should allow for min/max values and vocabulary restrictions on the values the idea behind TSAP and S3 is to allow the creation of an input form on the fly). Is this possible? | |||||||
> > | Section 2: This is not probably applicable to this document (more to DataService) but, in order to substitute the current SSAP approach for theoretical services with a VOResource approach, ParamHTTP (BaseParam) should allow for min/max values and vocabulary restrictions on the values (the idea behind TSAP and S3 is to allow the creation of an input form on the fly). Is this possible? | |||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Added: | ||||||||
> > | OK. We will take note of this as a possible enhacement of a future updated version of VODataService, then -- JesusSalgado - 2013-09-12 | |||||||
3.2.2.1 SkySize: In general, the allowed values are not to clear for some types. For example, SkySize seems to be in degrees but we only can know it by reading the help (as far as I know). It could be useful to allow for element restrictions (minInclussive, maxInclussive) that would help the validation. This is applicable to many other types like, e.g. SkyPos | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Added: | ||||||||
> > | I note that we explicitly state in the VOResource spec that the schema is not the sole standard of validity and that validaters need to go beyond the schema to fully validate a resource record. This choice was made explicitly to help cut down on complexity within the schema documents. I understand the risk so we can pass on this for this version -- JesusSalgado - 2013-09-12 | |||||||
Changed: | ||||||||
< < | Appendix: There are references to some xml namespaces not present in the location (like | |||||||
> > | Appendix: There are references to some xml namespaces not present in the location (like | |||||||
http://www.ivoa.net/xml/VOMetadata/v0.1It would be good to correct this in order to ensure a proper parsing. | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Added: | ||||||||
> > |
Not sure. If we leave then, the unresolved link should be "solved" at certain point. If we remove it, we can loose its possible use. I let you to decide what is the best approach. It is not a showstopper for me anyway -- JesusSalgado - 2013-09-12
| |||||||
A draft with corrections can be found on the SimpleDALRegExt page.
-- JesusSalgado - 2013-06-10
Grid & Web Services Working Group ( Andreas Wicenec, Andre Schaaff )Nothing to add to the already existing comments. Go ahead.Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner)
Semantics Working Group ( _Norman Gray, Mireille Louys)The Semantics WG approves this document. Sub-editing: p2, The expansion of the 'XML' acronym appears, from the XML standard, to be "Extensible Markup Language", not "eXtensible Markup Language" From RayPlante: so corrected (see pending draft).Data Curation & Preservation Interest Group ( Alberto Accomazzi, Françoise Genova )Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Knowledge Discovery in Databases Interest Group ( George Djorgovski )Theory Interest Group ( _Franck Le Petit, Rick Wagner )Time Domain Interest Group ( _Matthew Graham, John Swinbank )I approve this document. -- MatthewGraham - 2013-05-01Standards and Processes Committee ( Françoise Genova )<--
|
Request for Comment: SimpleDALRegExt v1.0This document serves as the RFC center for the Proposed Recommendation entitled "Describing Simple Data Access Services, Version 1.0". The version reviewed during the RFC can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20120517/. The version revised for TCG Review can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20121116/. RFC Review period: May 23, 2012 - June 27, 2012 CompletedTCG Review period: 4 Dec 2012 - 4 Jan 2013 Exec Approved for REC: Attention TCG: if you prefer printing out a PDF version for review, consider this abbreviated version. It omits the inclusion of the appendices listing the full XML schemas, resulting in 50% fewer pages.To add a comment on 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 that 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. Additional discussion about any of the comments or responses can be conducted on the Resource 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 Notes on Implementations and ValidatersThe SimpleDALRegExt page includes several compliant sample VOResource instances that use the extension schemas defined in the spec.. Instances can be validated with an XML Schema validater such as the one provided with Junx (which is based on Xerxes). Previous versions of the extensions for ConeSearch, SIA, and SSA, which the PR versions are backward-compatible with, have been in production use by IVOA-compliant registries for several years.Comments from the communityComments from MarkTaylorA couple of comments about the schema:
Comments from TheresaDower(pardon any major formatting issues; twiki is not being kind to my preview/editing attempts) I will admit I am unsure how much this document is supposed to be an administrative collation of the existing standards and how much we intend to change each of them with an eye on backward compatibility. This may or may not be the stage at which to address inconsistencies between the standards, but I can't think of a better one. (It may also be well past time, as I note we've already gone over the RFC date but are requesting more feedback.)
Comments from Randy ThompsonComments and questions (as sent to Ray last month) * General:
"The sky coordinate axes may not particularly parallel with the image axes (e.g. due to rotation or projection effects); in this case, the longitudinal side should be considered the side of the image that it cuts the smallest angle with."Why not just define maxImageSize as the x,y dimensions in pixels of the largest image that can be requested? I suspect this is what most data providers do anyway.
"A VOResource resource description must not include both a ssap:SimpleSpectralAccess capability and a ssap:ProtoSpectralAccess capability that describe the same service base URL, as given by the <interface>'S<accessURL>."I'm not sure what "<interface>'S<accessURL>"means, but does this sentence imply our services are no longer allowed?
Comments from TCG members during the TCG Review Period: 04/Dec/2012 – 04/Jan/2013WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham )Applications Working Group ( _Mark Taylor, Pierre Fernique )Looks good, just a few errors/queries, mostly in section 3.3.2:
| ||||||||
Changed: | ||||||||
< < | From RayPlante: all good catches; a draft with these corrections can be found on the SimpleDALRegExt page. | |||||||
> > | From RayPlante: all good catches; a draft with these corrections can be found on the SimpleDALRegExt page. | |||||||
Data Access Layer Working Group ( Patrick Dowler, Mike Fitzpatrick )1. Is there a way to specify allowed enumerated values in a capability custom <param> element? Specifically, if a service has some custom params with a small number of allowed values, this can say be expressed in the VOTable metadata response. Is that the only way or can they also put it in the registry record? 2. For SIA services, the maxImageExtent and skySize should specify units are in degrees. 3. Why is there no 'complianceLevel' for SIA? At least minimal/full values that say whether the 'should' is implemented or not. 4. Under SSA, 'maxFileSize' says "maximum image size" in the semantic meaning Comment: I was able to implement VOSICapabilities for the CADC SIA service using this spec; the only problem was finding the schema file (at the time) so I could perform validation. http://www.cadc.hia.nrc.gc.ca/sia/capabilities Clarification or explanation to improve the document is a sufficient response. Approved From RayPlante: | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Added: | ||||||||
> > | A draft with these corrections can be found on the SimpleDALRegExt page. | |||||||
-- PatrickDowler - 2013-05-17
Data Model Working Group ( _Jesus Salgado, Omar Laurino )Approved | ||||||||
Changed: | ||||||||
< < | Some small comments: | |||||||
> > | Some small comments (with response from RayPlante): | |||||||
Changed: | ||||||||
< < | Introduction: typo -> whereever | |||||||
> > | Introduction: typo -> whereever (RayPlante: thanks) | |||||||
Section 2: This is not probably applicable to this document (more to DataService) but, in order to substitute the current SSAP approach for theoretical services with a VOResource approach, ParamHTTP (BaseParam) should allow for min/max values and vocabulary restrictions on the values the idea behind TSAP and S3 is to allow the creation of an input form on the fly). Is this possible? | ||||||||
Added: | ||||||||
> > |
| |||||||
3.2.2.1 SkySize: In general, the allowed values are not to clear for some types. For example, SkySize seems to be in degrees but we only can know it by reading the help (as far as I know). It could be useful to allow for element restrictions (minInclussive, maxInclussive) that would help the validation. This is applicable to many other types like, e.g. SkyPos | ||||||||
Added: | ||||||||
> > |
| |||||||
Appendix: There are references to some xml namespaces not present in the location (like
http://www.ivoa.net/xml/VOMetadata/v0.1It would be good to correct this in order to ensure a proper parsing. | ||||||||
Added: | ||||||||
> > |
| |||||||
-- JesusSalgado - 2013-06-10
Grid & Web Services Working Group ( Andreas Wicenec, Andre Schaaff )Nothing to add to the already existing comments. Go ahead.Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner)
| ||||||||
Changed: | ||||||||
< < | From RayPlante: a draft with these corrections can be found on the SimpleDALRegExt page. | |||||||
> > | From RayPlante: a draft with these corrections can be found on the SimpleDALRegExt page. | |||||||
Semantics Working Group ( _Norman Gray, Mireille Louys)The Semantics WG approves this document. Sub-editing: p2, The expansion of the 'XML' acronym appears, from the XML standard, to be "Extensible Markup Language", not "eXtensible Markup Language" | ||||||||
Added: | ||||||||
> > | From RayPlante: so corrected (see pending draft). | |||||||
Data Curation & Preservation Interest Group ( Alberto Accomazzi, Françoise Genova )Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Knowledge Discovery in Databases Interest Group ( George Djorgovski )Theory Interest Group ( _Franck Le Petit, Rick Wagner )Time Domain Interest Group ( _Matthew Graham, John Swinbank )I approve this document. -- MatthewGraham - 2013-05-01Standards and Processes Committee ( Françoise Genova )<--
|
Request for Comment: SimpleDALRegExt v1.0This document serves as the RFC center for the Proposed Recommendation entitled "Describing Simple Data Access Services, Version 1.0". The version reviewed during the RFC can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20120517/. The version revised for TCG Review can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20121116/. RFC Review period: May 23, 2012 - June 27, 2012 CompletedTCG Review period: 4 Dec 2012 - 4 Jan 2013 Exec Approved for REC: Attention TCG: if you prefer printing out a PDF version for review, consider this abbreviated version. It omits the inclusion of the appendices listing the full XML schemas, resulting in 50% fewer pages.To add a comment on 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 that 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. Additional discussion about any of the comments or responses can be conducted on the Resource 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 Notes on Implementations and ValidatersThe SimpleDALRegExt page includes several compliant sample VOResource instances that use the extension schemas defined in the spec.. Instances can be validated with an XML Schema validater such as the one provided with Junx (which is based on Xerxes). Previous versions of the extensions for ConeSearch, SIA, and SSA, which the PR versions are backward-compatible with, have been in production use by IVOA-compliant registries for several years.Comments from the communityComments from MarkTaylorA couple of comments about the schema:
Comments from TheresaDower(pardon any major formatting issues; twiki is not being kind to my preview/editing attempts) I will admit I am unsure how much this document is supposed to be an administrative collation of the existing standards and how much we intend to change each of them with an eye on backward compatibility. This may or may not be the stage at which to address inconsistencies between the standards, but I can't think of a better one. (It may also be well past time, as I note we've already gone over the RFC date but are requesting more feedback.)
Comments from Randy ThompsonComments and questions (as sent to Ray last month) * General:
"The sky coordinate axes may not particularly parallel with the image axes (e.g. due to rotation or projection effects); in this case, the longitudinal side should be considered the side of the image that it cuts the smallest angle with."Why not just define maxImageSize as the x,y dimensions in pixels of the largest image that can be requested? I suspect this is what most data providers do anyway.
"A VOResource resource description must not include both a ssap:SimpleSpectralAccess capability and a ssap:ProtoSpectralAccess capability that describe the same service base URL, as given by the <interface>'S<accessURL>."I'm not sure what "<interface>'S<accessURL>"means, but does this sentence imply our services are no longer allowed?
Comments from TCG members during the TCG Review Period: 04/Dec/2012 – 04/Jan/2013WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham )Applications Working Group ( _Mark Taylor, Pierre Fernique )Looks good, just a few errors/queries, mostly in section 3.3.2:
Data Access Layer Working Group ( Patrick Dowler, Mike Fitzpatrick )1. Is there a way to specify allowed enumerated values in a capability custom <param> element? Specifically, if a service has some custom params with a small number of allowed values, this can say be expressed in the VOTable metadata response. Is that the only way or can they also put it in the registry record? 2. For SIA services, the maxImageExtent and skySize should specify units are in degrees. 3. Why is there no 'complianceLevel' for SIA? At least minimal/full values that say whether the 'should' is implemented or not. 4. Under SSA, 'maxFileSize' says "maximum image size" in the semantic meaning Comment: I was able to implement VOSICapabilities for the CADC SIA service using this spec; the only problem was finding the schema file (at the time) so I could perform validation. http://www.cadc.hia.nrc.gc.ca/sia/capabilities Clarification or explanation to improve the document is a sufficient response. Approved | ||||||||
Added: | ||||||||
> > |
From RayPlante:
| |||||||
-- PatrickDowler - 2013-05-17
Data Model Working Group ( _Jesus Salgado, Omar Laurino )Approved Some small comments: Introduction: typo -> whereever Section 2: This is not probably applicable to this document (more to DataService) but, in order to substitute the current SSAP approach for theoretical services with a VOResource approach, ParamHTTP (BaseParam) should allow for min/max values and vocabulary restrictions on the values the idea behind TSAP and S3 is to allow the creation of an input form on the fly). Is this possible? 3.2.2.1 SkySize: In general, the allowed values are not to clear for some types. For example, SkySize seems to be in degrees but we only can know it by reading the help (as far as I know). It could be useful to allow for element restrictions (minInclussive, maxInclussive) that would help the validation. This is applicable to many other types like, e.g. SkyPos Appendix: There are references to some xml namespaces not present in the location (likehttp://www.ivoa.net/xml/VOMetadata/v0.1It would be good to correct this in order to ensure a proper parsing. -- JesusSalgado - 2013-06-10 Grid & Web Services Working Group ( Andreas Wicenec, Andre Schaaff )Nothing to add to the already existing comments. Go ahead.Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner)
Semantics Working Group ( _Norman Gray, Mireille Louys)The Semantics WG approves this document. Sub-editing: p2, The expansion of the 'XML' acronym appears, from the XML standard, to be "Extensible Markup Language", not "eXtensible Markup Language"Data Curation & Preservation Interest Group ( Alberto Accomazzi, Françoise Genova )Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Knowledge Discovery in Databases Interest Group ( George Djorgovski )Theory Interest Group ( _Franck Le Petit, Rick Wagner )Time Domain Interest Group ( _Matthew Graham, John Swinbank )I approve this document. -- MatthewGraham - 2013-05-01Standards and Processes Committee ( Françoise Genova )<--
|
Request for Comment: SimpleDALRegExt v1.0This document serves as the RFC center for the Proposed Recommendation entitled "Describing Simple Data Access Services, Version 1.0". The version reviewed during the RFC can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20120517/. The version revised for TCG Review can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20121116/. RFC Review period: May 23, 2012 - June 27, 2012 CompletedTCG Review period: 4 Dec 2012 - 4 Jan 2013 Exec Approved for REC: Attention TCG: if you prefer printing out a PDF version for review, consider this abbreviated version. It omits the inclusion of the appendices listing the full XML schemas, resulting in 50% fewer pages.To add a comment on 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 that 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. Additional discussion about any of the comments or responses can be conducted on the Resource 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 Notes on Implementations and ValidatersThe SimpleDALRegExt page includes several compliant sample VOResource instances that use the extension schemas defined in the spec.. Instances can be validated with an XML Schema validater such as the one provided with Junx (which is based on Xerxes). Previous versions of the extensions for ConeSearch, SIA, and SSA, which the PR versions are backward-compatible with, have been in production use by IVOA-compliant registries for several years.Comments from the communityComments from MarkTaylorA couple of comments about the schema:
Comments from TheresaDower(pardon any major formatting issues; twiki is not being kind to my preview/editing attempts) I will admit I am unsure how much this document is supposed to be an administrative collation of the existing standards and how much we intend to change each of them with an eye on backward compatibility. This may or may not be the stage at which to address inconsistencies between the standards, but I can't think of a better one. (It may also be well past time, as I note we've already gone over the RFC date but are requesting more feedback.)
Comments from Randy ThompsonComments and questions (as sent to Ray last month) * General:
"The sky coordinate axes may not particularly parallel with the image axes (e.g. due to rotation or projection effects); in this case, the longitudinal side should be considered the side of the image that it cuts the smallest angle with."Why not just define maxImageSize as the x,y dimensions in pixels of the largest image that can be requested? I suspect this is what most data providers do anyway.
"A VOResource resource description must not include both a ssap:SimpleSpectralAccess capability and a ssap:ProtoSpectralAccess capability that describe the same service base URL, as given by the <interface>'S<accessURL>."I'm not sure what "<interface>'S<accessURL>"means, but does this sentence imply our services are no longer allowed?
Comments from TCG members during the TCG Review Period: 04/Dec/2012 – 04/Jan/2013WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham )Applications Working Group ( _Mark Taylor, Pierre Fernique )Looks good, just a few errors/queries, mostly in section 3.3.2:
Data Access Layer Working Group ( Patrick Dowler, Mike Fitzpatrick )1. Is there a way to specify allowed enumerated values in a capability custom <param> element? Specifically, if a service has some custom params with a small number of allowed values, this can say be expressed in the VOTable metadata response. Is that the only way or can they also put it in the registry record? 2. For SIA services, the maxImageExtent and skySize should specify units are in degrees. 3. Why is there no 'complianceLevel' for SIA? At least minimal/full values that say whether the 'should' is implemented or not. 4. Under SSA, 'maxFileSize' says "maximum image size" in the semantic meaning Comment: I was able to implement VOSICapabilities for the CADC SIA service using this spec; the only problem was finding the schema file (at the time) so I could perform validation. http://www.cadc.hia.nrc.gc.ca/sia/capabilities Clarification or explanation to improve the document is a sufficient response. Approved -- PatrickDowler - 2013-05-17Data Model Working Group ( _Jesus Salgado, Omar Laurino ) | ||||||||
Added: | ||||||||
> > | Approved
Some small comments:
Introduction: typo -> whereever
Section 2: This is not probably applicable to this document (more to DataService) but, in order to substitute the current SSAP approach for theoretical services with a VOResource approach, ParamHTTP (BaseParam) should allow for min/max values and vocabulary restrictions on the values the idea behind TSAP and S3 is to allow the creation of an input form on the fly). Is this possible?
3.2.2.1 SkySize: In general, the allowed values are not to clear for some types. For example, SkySize seems to be in degrees but we only can know it by reading the help (as far as I know). It could be useful to allow for element restrictions (minInclussive, maxInclussive) that would help the validation. This is applicable to many other types like, e.g. SkyPos
Appendix: There are references to some xml namespaces not present in the location (like
http://www.ivoa.net/xml/VOMetadata/v0.1It would be good to correct this in order to ensure a proper parsing. -- JesusSalgado - 2013-06-10 | |||||||
Grid & Web Services Working Group ( Andreas Wicenec, Andre Schaaff )Nothing to add to the already existing comments. Go ahead.Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner)
Semantics Working Group ( _Norman Gray, Mireille Louys)The Semantics WG approves this document. Sub-editing: p2, The expansion of the 'XML' acronym appears, from the XML standard, to be "Extensible Markup Language", not "eXtensible Markup Language"Data Curation & Preservation Interest Group ( Alberto Accomazzi, Françoise Genova )Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Knowledge Discovery in Databases Interest Group ( George Djorgovski )Theory Interest Group ( _Franck Le Petit, Rick Wagner )Time Domain Interest Group ( _Matthew Graham, John Swinbank )I approve this document. -- MatthewGraham - 2013-05-01Standards and Processes Committee ( Françoise Genova )<--
|
Request for Comment: SimpleDALRegExt v1.0This document serves as the RFC center for the Proposed Recommendation entitled "Describing Simple Data Access Services, Version 1.0". The version reviewed during the RFC can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20120517/. The version revised for TCG Review can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20121116/. RFC Review period: May 23, 2012 - June 27, 2012 CompletedTCG Review period: 4 Dec 2012 - 4 Jan 2013 Exec Approved for REC: Attention TCG: if you prefer printing out a PDF version for review, consider this abbreviated version. It omits the inclusion of the appendices listing the full XML schemas, resulting in 50% fewer pages.To add a comment on 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 that 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. Additional discussion about any of the comments or responses can be conducted on the Resource 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 Notes on Implementations and ValidatersThe SimpleDALRegExt page includes several compliant sample VOResource instances that use the extension schemas defined in the spec.. Instances can be validated with an XML Schema validater such as the one provided with Junx (which is based on Xerxes). Previous versions of the extensions for ConeSearch, SIA, and SSA, which the PR versions are backward-compatible with, have been in production use by IVOA-compliant registries for several years.Comments from the communityComments from MarkTaylorA couple of comments about the schema:
Comments from TheresaDower(pardon any major formatting issues; twiki is not being kind to my preview/editing attempts) I will admit I am unsure how much this document is supposed to be an administrative collation of the existing standards and how much we intend to change each of them with an eye on backward compatibility. This may or may not be the stage at which to address inconsistencies between the standards, but I can't think of a better one. (It may also be well past time, as I note we've already gone over the RFC date but are requesting more feedback.)
Comments from Randy ThompsonComments and questions (as sent to Ray last month) * General:
"The sky coordinate axes may not particularly parallel with the image axes (e.g. due to rotation or projection effects); in this case, the longitudinal side should be considered the side of the image that it cuts the smallest angle with."Why not just define maxImageSize as the x,y dimensions in pixels of the largest image that can be requested? I suspect this is what most data providers do anyway.
"A VOResource resource description must not include both a ssap:SimpleSpectralAccess capability and a ssap:ProtoSpectralAccess capability that describe the same service base URL, as given by the <interface>'S<accessURL>."I'm not sure what "<interface>'S<accessURL>"means, but does this sentence imply our services are no longer allowed?
Comments from TCG members during the TCG Review Period: 04/Dec/2012 – 04/Jan/2013WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham )Applications Working Group ( _Mark Taylor, Pierre Fernique )Looks good, just a few errors/queries, mostly in section 3.3.2:
Data Access Layer Working Group ( Patrick Dowler, Mike Fitzpatrick ) | ||||||||
Added: | ||||||||
> > | 1. Is there a way to specify allowed enumerated values in a capability custom <param> element? Specifically, if a service has some custom params with a small number of allowed values, this can say be expressed in the VOTable metadata response. Is that the only way or can they also put it in the registry record? 2. For SIA services, the maxImageExtent and skySize should specify units are in degrees. 3. Why is there no 'complianceLevel' for SIA? At least minimal/full values that say whether the 'should' is implemented or not. 4. Under SSA, 'maxFileSize' says "maximum image size" in the semantic meaning Comment: I was able to implement VOSICapabilities for the CADC SIA service using this spec; the only problem was finding the schema file (at the time) so I could perform validation. http://www.cadc.hia.nrc.gc.ca/sia/capabilities Clarification or explanation to improve the document is a sufficient response. Approved -- PatrickDowler - 2013-05-17 | |||||||
Data Model Working Group ( _Jesus Salgado, Omar Laurino )Grid & Web Services Working Group ( Andreas Wicenec, Andre Schaaff )Nothing to add to the already existing comments. Go ahead.Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner)
Semantics Working Group ( _Norman Gray, Mireille Louys)The Semantics WG approves this document. Sub-editing: p2, The expansion of the 'XML' acronym appears, from the XML standard, to be "Extensible Markup Language", not "eXtensible Markup Language"Data Curation & Preservation Interest Group ( Alberto Accomazzi, Françoise Genova )Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Knowledge Discovery in Databases Interest Group ( George Djorgovski )Theory Interest Group ( _Franck Le Petit, Rick Wagner )Time Domain Interest Group ( _Matthew Graham, John Swinbank )I approve this document. -- MatthewGraham - 2013-05-01Standards and Processes Committee ( Françoise Genova )<--
|
Request for Comment: SimpleDALRegExt v1.0This document serves as the RFC center for the Proposed Recommendation entitled "Describing Simple Data Access Services, Version 1.0". The version reviewed during the RFC can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20120517/. The version revised for TCG Review can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20121116/. RFC Review period: May 23, 2012 - June 27, 2012 CompletedTCG Review period: 4 Dec 2012 - 4 Jan 2013 Exec Approved for REC: Attention TCG: if you prefer printing out a PDF version for review, consider this abbreviated version. It omits the inclusion of the appendices listing the full XML schemas, resulting in 50% fewer pages.To add a comment on 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 that 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. Additional discussion about any of the comments or responses can be conducted on the Resource 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 Notes on Implementations and ValidatersThe SimpleDALRegExt page includes several compliant sample VOResource instances that use the extension schemas defined in the spec.. Instances can be validated with an XML Schema validater such as the one provided with Junx (which is based on Xerxes). Previous versions of the extensions for ConeSearch, SIA, and SSA, which the PR versions are backward-compatible with, have been in production use by IVOA-compliant registries for several years.Comments from the communityComments from MarkTaylorA couple of comments about the schema:
Comments from TheresaDower(pardon any major formatting issues; twiki is not being kind to my preview/editing attempts) I will admit I am unsure how much this document is supposed to be an administrative collation of the existing standards and how much we intend to change each of them with an eye on backward compatibility. This may or may not be the stage at which to address inconsistencies between the standards, but I can't think of a better one. (It may also be well past time, as I note we've already gone over the RFC date but are requesting more feedback.)
Comments from Randy ThompsonComments and questions (as sent to Ray last month) * General:
"The sky coordinate axes may not particularly parallel with the image axes (e.g. due to rotation or projection effects); in this case, the longitudinal side should be considered the side of the image that it cuts the smallest angle with."Why not just define maxImageSize as the x,y dimensions in pixels of the largest image that can be requested? I suspect this is what most data providers do anyway.
"A VOResource resource description must not include both a ssap:SimpleSpectralAccess capability and a ssap:ProtoSpectralAccess capability that describe the same service base URL, as given by the <interface>'S<accessURL>."I'm not sure what "<interface>'S<accessURL>"means, but does this sentence imply our services are no longer allowed?
Comments from TCG members during the TCG Review Period: 04/Dec/2012 – 04/Jan/2013WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham )Applications Working Group ( _Mark Taylor, Pierre Fernique )Looks good, just a few errors/queries, mostly in section 3.3.2:
Data Access Layer Working Group ( Patrick Dowler, Mike Fitzpatrick )Data Model Working Group ( _Jesus Salgado, Omar Laurino )Grid & Web Services Working Group ( Andreas Wicenec, Andre Schaaff ) | ||||||||
Added: | ||||||||
> > | Nothing to add to the already existing comments. Go ahead. | |||||||
Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner)
Semantics Working Group ( _Norman Gray, Mireille Louys)The Semantics WG approves this document. | ||||||||
Changed: | ||||||||
< < | Sub-editing: p2, The expansion of the 'XML' acronym appears, from the XML standard, | |||||||
> > | Sub-editing: p2, The expansion of the 'XML' acronym appears, from the XML standard, to be "Extensible Markup Language", not "eXtensible Markup Language" | |||||||
Deleted: | ||||||||
< < | to be "Extensible Markup Language", not "eXtensible Markup Language" | |||||||
Data Curation & Preservation Interest Group ( Alberto Accomazzi, Françoise Genova )Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Knowledge Discovery in Databases Interest Group ( George Djorgovski )Theory Interest Group ( _Franck Le Petit, Rick Wagner )Time Domain Interest Group ( _Matthew Graham, John Swinbank )I approve this document. -- MatthewGraham - 2013-05-01Standards and Processes Committee ( Françoise Genova )<--
|
Request for Comment: SimpleDALRegExt v1.0This document serves as the RFC center for the Proposed Recommendation entitled "Describing Simple Data Access Services, Version 1.0". The version reviewed during the RFC can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20120517/. The version revised for TCG Review can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20121116/. RFC Review period: May 23, 2012 - June 27, 2012 CompletedTCG Review period: 4 Dec 2012 - 4 Jan 2013 Exec Approved for REC: Attention TCG: if you prefer printing out a PDF version for review, consider this abbreviated version. It omits the inclusion of the appendices listing the full XML schemas, resulting in 50% fewer pages.To add a comment on 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 that 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. Additional discussion about any of the comments or responses can be conducted on the Resource 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 Notes on Implementations and ValidatersThe SimpleDALRegExt page includes several compliant sample VOResource instances that use the extension schemas defined in the spec.. Instances can be validated with an XML Schema validater such as the one provided with Junx (which is based on Xerxes). Previous versions of the extensions for ConeSearch, SIA, and SSA, which the PR versions are backward-compatible with, have been in production use by IVOA-compliant registries for several years.Comments from the communityComments from MarkTaylorA couple of comments about the schema:
Comments from TheresaDower(pardon any major formatting issues; twiki is not being kind to my preview/editing attempts) I will admit I am unsure how much this document is supposed to be an administrative collation of the existing standards and how much we intend to change each of them with an eye on backward compatibility. This may or may not be the stage at which to address inconsistencies between the standards, but I can't think of a better one. (It may also be well past time, as I note we've already gone over the RFC date but are requesting more feedback.)
Comments from Randy ThompsonComments and questions (as sent to Ray last month) * General:
"The sky coordinate axes may not particularly parallel with the image axes (e.g. due to rotation or projection effects); in this case, the longitudinal side should be considered the side of the image that it cuts the smallest angle with."Why not just define maxImageSize as the x,y dimensions in pixels of the largest image that can be requested? I suspect this is what most data providers do anyway.
"A VOResource resource description must not include both a ssap:SimpleSpectralAccess capability and a ssap:ProtoSpectralAccess capability that describe the same service base URL, as given by the <interface>'S<accessURL>."I'm not sure what "<interface>'S<accessURL>"means, but does this sentence imply our services are no longer allowed?
Comments from TCG members during the TCG Review Period: 04/Dec/2012 – 04/Jan/2013WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham )Applications Working Group ( _Mark Taylor, Pierre Fernique )Looks good, just a few errors/queries, mostly in section 3.3.2:
Data Access Layer Working Group ( Patrick Dowler, Mike Fitzpatrick )Data Model Working Group ( _Jesus Salgado, Omar Laurino )Grid & Web Services Working Group ( Andreas Wicenec, Andre Schaaff )Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner)
Semantics Working Group ( _Norman Gray, Mireille Louys) | ||||||||
Added: | ||||||||
> > | The Semantics WG approves this document. Sub-editing: p2, The expansion of the 'XML' acronym appears, from the XML standard, to be "Extensible Markup Language", not "eXtensible Markup Language" | |||||||
Data Curation & Preservation Interest Group ( Alberto Accomazzi, Françoise Genova )Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Knowledge Discovery in Databases Interest Group ( George Djorgovski )Theory Interest Group ( _Franck Le Petit, Rick Wagner )Time Domain Interest Group ( _Matthew Graham, John Swinbank )I approve this document. -- MatthewGraham - 2013-05-01Standards and Processes Committee ( Françoise Genova )<--
|
Request for Comment: SimpleDALRegExt v1.0This document serves as the RFC center for the Proposed Recommendation entitled "Describing Simple Data Access Services, Version 1.0". The version reviewed during the RFC can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20120517/. The version revised for TCG Review can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20121116/. RFC Review period: May 23, 2012 - June 27, 2012 CompletedTCG Review period: 4 Dec 2012 - 4 Jan 2013 Exec Approved for REC: Attention TCG: if you prefer printing out a PDF version for review, consider this abbreviated version. It omits the inclusion of the appendices listing the full XML schemas, resulting in 50% fewer pages.To add a comment on 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 that 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. Additional discussion about any of the comments or responses can be conducted on the Resource 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 Notes on Implementations and ValidatersThe SimpleDALRegExt page includes several compliant sample VOResource instances that use the extension schemas defined in the spec.. Instances can be validated with an XML Schema validater such as the one provided with Junx (which is based on Xerxes). Previous versions of the extensions for ConeSearch, SIA, and SSA, which the PR versions are backward-compatible with, have been in production use by IVOA-compliant registries for several years.Comments from the communityComments from MarkTaylorA couple of comments about the schema:
Comments from TheresaDower(pardon any major formatting issues; twiki is not being kind to my preview/editing attempts) I will admit I am unsure how much this document is supposed to be an administrative collation of the existing standards and how much we intend to change each of them with an eye on backward compatibility. This may or may not be the stage at which to address inconsistencies between the standards, but I can't think of a better one. (It may also be well past time, as I note we've already gone over the RFC date but are requesting more feedback.)
Comments from Randy ThompsonComments and questions (as sent to Ray last month) * General:
"The sky coordinate axes may not particularly parallel with the image axes (e.g. due to rotation or projection effects); in this case, the longitudinal side should be considered the side of the image that it cuts the smallest angle with."Why not just define maxImageSize as the x,y dimensions in pixels of the largest image that can be requested? I suspect this is what most data providers do anyway.
"A VOResource resource description must not include both a ssap:SimpleSpectralAccess capability and a ssap:ProtoSpectralAccess capability that describe the same service base URL, as given by the <interface>'S<accessURL>."I'm not sure what "<interface>'S<accessURL>"means, but does this sentence imply our services are no longer allowed?
| ||||||||
Changed: | ||||||||
< < | Comments from TCG members during the TCG Review Period: 04/Dec/2012 – 04/Jan/2013 | |||||||
> > | Comments from TCG members during the TCG Review Period: 04/Dec/2012 – 04/Jan/2013 | |||||||
WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard.
IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.
TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham )Applications Working Group ( _Mark Taylor, Pierre Fernique )Looks good, just a few errors/queries, mostly in section 3.3.2:
Data Access Layer Working Group ( Patrick Dowler, Mike Fitzpatrick )Data Model Working Group ( _Jesus Salgado, Omar Laurino )Grid & Web Services Working Group ( Andreas Wicenec, Andre Schaaff )Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner) | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Deleted: | ||||||||
< < | ||||||||
Following these corrections RWG approves. -- GretchenGreene - 2012-12-14
From RayPlante: a draft with these corrections can be found on the SimpleDALRegExt page.
Semantics Working Group ( _Norman Gray, Mireille Louys)Data Curation & Preservation Interest Group ( Alberto Accomazzi, Françoise Genova )Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Knowledge Discovery in Databases Interest Group ( George Djorgovski )Theory Interest Group ( _Franck Le Petit, Rick Wagner )Time Domain Interest Group ( _Matthew Graham, John Swinbank ) | ||||||||
Added: | ||||||||
> > | I approve this document. -- MatthewGraham - 2013-05-01 | |||||||
Standards and Processes Committee ( Françoise Genova )<--
|
Request for Comment: SimpleDALRegExt v1.0This document serves as the RFC center for the Proposed Recommendation entitled "Describing Simple Data Access Services, Version 1.0". The version reviewed during the RFC can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20120517/. The version revised for TCG Review can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20121116/. RFC Review period: May 23, 2012 - June 27, 2012 CompletedTCG Review period: 4 Dec 2012 - 4 Jan 2013 Exec Approved for REC: Attention TCG: if you prefer printing out a PDF version for review, consider this abbreviated version. It omits the inclusion of the appendices listing the full XML schemas, resulting in 50% fewer pages.To add a comment on 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 that 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. Additional discussion about any of the comments or responses can be conducted on the Resource 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 Notes on Implementations and ValidatersThe SimpleDALRegExt page includes several compliant sample VOResource instances that use the extension schemas defined in the spec.. Instances can be validated with an XML Schema validater such as the one provided with Junx (which is based on Xerxes). Previous versions of the extensions for ConeSearch, SIA, and SSA, which the PR versions are backward-compatible with, have been in production use by IVOA-compliant registries for several years.Comments from the communityComments from MarkTaylorA couple of comments about the schema:
Comments from TheresaDower(pardon any major formatting issues; twiki is not being kind to my preview/editing attempts) I will admit I am unsure how much this document is supposed to be an administrative collation of the existing standards and how much we intend to change each of them with an eye on backward compatibility. This may or may not be the stage at which to address inconsistencies between the standards, but I can't think of a better one. (It may also be well past time, as I note we've already gone over the RFC date but are requesting more feedback.)
Comments from Randy ThompsonComments and questions (as sent to Ray last month) * General:
"The sky coordinate axes may not particularly parallel with the image axes (e.g. due to rotation or projection effects); in this case, the longitudinal side should be considered the side of the image that it cuts the smallest angle with."Why not just define maxImageSize as the x,y dimensions in pixels of the largest image that can be requested? I suspect this is what most data providers do anyway.
"A VOResource resource description must not include both a ssap:SimpleSpectralAccess capability and a ssap:ProtoSpectralAccess capability that describe the same service base URL, as given by the <interface>'S<accessURL>."I'm not sure what "<interface>'S<accessURL>"means, but does this sentence imply our services are no longer allowed?
| ||||||||
Changed: | ||||||||
< < | Comments from TCG members during the TCG Review Period: ?? ???? 2012 - ?? ???? 2012 | |||||||
> > | Comments from TCG members during the TCG Review Period: 04/Dec/2012 – 04/Jan/2013 | |||||||
WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory. | ||||||||
Changed: | ||||||||
< < | TCG Chair & Vice Chair ( _Christophe Arviset, Séverin Gaudet) | |||||||
> > | TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham ) | |||||||
Changed: | ||||||||
< < | Applications Working Group ( _Mark Taylor, Pierre Fernique) | |||||||
> > | Applications Working Group ( _Mark Taylor, Pierre Fernique ) | |||||||
Looks good, just a few errors/queries, mostly in section 3.3.2:
| ||||||||
Changed: | ||||||||
< < | Data Access Layer Working Group ( Patrick Dowler, Mike Fitzpatrick) | |||||||
> > | Data Access Layer Working Group ( Patrick Dowler, Mike Fitzpatrick ) | |||||||
Changed: | ||||||||
< < | Data Model Working Group ( _Jesus Salgado, Omar Laurino) | |||||||
> > | Data Model Working Group ( _Jesus Salgado, Omar Laurino ) | |||||||
Grid & Web Services Working Group ( Andreas Wicenec, Andre Schaaff )Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner)
| ||||||||
Changed: | ||||||||
< < | Semantics Working Group ( _Sebastien Derriere, Norman Gray) | |||||||
> > | Semantics Working Group ( _Norman Gray, Mireille Louys) | |||||||
Changed: | ||||||||
< < | VOEvent Working Group ( _Matthew Graham, John Swinbank) | |||||||
> > | Data Curation & Preservation Interest Group ( Alberto Accomazzi, Françoise Genova ) | |||||||
Changed: | ||||||||
< < | Data Curation & Preservation Interest Group ( Alberto Accomazzi) | |||||||
> > | Education Interest Group ( _Massimo Ramella, Sudhanshu Barway ) | |||||||
Changed: | ||||||||
< < | Knowledge Discovery in Databases Interest Group ( Giuseppe Longo) | |||||||
> > | Knowledge Discovery in Databases Interest Group ( George Djorgovski ) | |||||||
Changed: | ||||||||
< < | Theory Interest Group ( _Herve Wozniak, Franck Le Petit) | |||||||
> > | Theory Interest Group ( _Franck Le Petit, Rick Wagner ) | |||||||
Changed: | ||||||||
< < | Standards and Processes Committee ( Francoise Genova) | |||||||
> > | Time Domain Interest Group ( _Matthew Graham, John Swinbank ) | |||||||
Added: | ||||||||
> > |
Standards and Processes Committee ( Françoise Genova ) | |||||||
<--
|
Request for Comment: SimpleDALRegExt v1.0This document serves as the RFC center for the Proposed Recommendation entitled "Describing Simple Data Access Services, Version 1.0". The version reviewed during the RFC can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20120517/. The version revised for TCG Review can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20121116/. RFC Review period: May 23, 2012 - June 27, 2012 CompletedTCG Review period: 4 Dec 2012 - 4 Jan 2013 Exec Approved for REC: Attention TCG: if you prefer printing out a PDF version for review, consider this abbreviated version. It omits the inclusion of the appendices listing the full XML schemas, resulting in 50% fewer pages.To add a comment on 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 that 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. Additional discussion about any of the comments or responses can be conducted on the Resource 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 Notes on Implementations and ValidatersThe SimpleDALRegExt page includes several compliant sample VOResource instances that use the extension schemas defined in the spec.. Instances can be validated with an XML Schema validater such as the one provided with Junx (which is based on Xerxes). Previous versions of the extensions for ConeSearch, SIA, and SSA, which the PR versions are backward-compatible with, have been in production use by IVOA-compliant registries for several years.Comments from the communityComments from MarkTaylorA couple of comments about the schema:
Comments from TheresaDower(pardon any major formatting issues; twiki is not being kind to my preview/editing attempts) I will admit I am unsure how much this document is supposed to be an administrative collation of the existing standards and how much we intend to change each of them with an eye on backward compatibility. This may or may not be the stage at which to address inconsistencies between the standards, but I can't think of a better one. (It may also be well past time, as I note we've already gone over the RFC date but are requesting more feedback.)
Comments from Randy ThompsonComments and questions (as sent to Ray last month) * General:
"The sky coordinate axes may not particularly parallel with the image axes (e.g. due to rotation or projection effects); in this case, the longitudinal side should be considered the side of the image that it cuts the smallest angle with."Why not just define maxImageSize as the x,y dimensions in pixels of the largest image that can be requested? I suspect this is what most data providers do anyway.
"A VOResource resource description must not include both a ssap:SimpleSpectralAccess capability and a ssap:ProtoSpectralAccess capability that describe the same service base URL, as given by the <interface>'S<accessURL>."I'm not sure what "<interface>'S<accessURL>"means, but does this sentence imply our services are no longer allowed?
Comments from TCG members during the TCG Review Period: ?? ???? 2012 - ?? ???? 2012WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice Chair ( _Christophe Arviset, Séverin Gaudet)Applications Working Group ( _Mark Taylor, Pierre Fernique)Looks good, just a few errors/queries, mostly in section 3.3.2:
| ||||||||
Added: | ||||||||
> > | From RayPlante: all good catches; a draft with these corrections can be found on the SimpleDALRegExt page. | |||||||
Data Access Layer Working Group ( Patrick Dowler, Mike Fitzpatrick)Data Model Working Group ( _Jesus Salgado, Omar Laurino)Grid & Web Services Working Group ( Andreas Wicenec, Andre Schaaff )Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner)
| ||||||||
Added: | ||||||||
> > | From RayPlante: a draft with these corrections can be found on the SimpleDALRegExt page. | |||||||
Semantics Working Group ( _Sebastien Derriere, Norman Gray)VOEvent Working Group ( _Matthew Graham, John Swinbank)Data Curation & Preservation Interest Group ( Alberto Accomazzi)Knowledge Discovery in Databases Interest Group ( Giuseppe Longo)Theory Interest Group ( _Herve Wozniak, Franck Le Petit)Standards and Processes Committee ( Francoise Genova)<--
|
Request for Comment: SimpleDALRegExt v1.0This document serves as the RFC center for the Proposed Recommendation entitled "Describing Simple Data Access Services, Version 1.0". The version reviewed during the RFC can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20120517/. The version revised for TCG Review can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20121116/. RFC Review period: May 23, 2012 - June 27, 2012 CompletedTCG Review period: 4 Dec 2012 - 4 Jan 2013 Exec Approved for REC: | ||||||||
Changed: | ||||||||
< < | ||||||||
> > | Attention TCG: if you prefer printing out a PDF version for review, consider this abbreviated version. It omits the inclusion of the appendices listing the full XML schemas, resulting in 50% fewer pages. | |||||||
Deleted: | ||||||||
< < | Attention TCG: if you prefer printing out a PDF version for review, consider this abbreviated version. It omits the inclusion of the appendices listing the full XML schemas, resulting in 50% fewer pages. | |||||||
To add a comment on 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 that 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.
Additional discussion about any of the comments or responses can be conducted on the Resource 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
Notes on Implementations and ValidatersThe SimpleDALRegExt page includes several compliant sample VOResource instances that use the extension schemas defined in the spec.. Instances can be validated with an XML Schema validater such as the one provided with Junx (which is based on Xerxes). Previous versions of the extensions for ConeSearch, SIA, and SSA, which the PR versions are backward-compatible with, have been in production use by IVOA-compliant registries for several years.Comments from the communityComments from MarkTaylorA couple of comments about the schema:
Comments from TheresaDower(pardon any major formatting issues; twiki is not being kind to my preview/editing attempts) I will admit I am unsure how much this document is supposed to be an administrative collation of the existing standards and how much we intend to change each of them with an eye on backward compatibility. This may or may not be the stage at which to address inconsistencies between the standards, but I can't think of a better one. (It may also be well past time, as I note we've already gone over the RFC date but are requesting more feedback.)
Comments from Randy ThompsonComments and questions (as sent to Ray last month) * General:
"The sky coordinate axes may not particularly parallel with the image axes (e.g. due to rotation or projection effects); in this case, the longitudinal side should be considered the side of the image that it cuts the smallest angle with."Why not just define maxImageSize as the x,y dimensions in pixels of the largest image that can be requested? I suspect this is what most data providers do anyway.
"A VOResource resource description must not include both a ssap:SimpleSpectralAccess capability and a ssap:ProtoSpectralAccess capability that describe the same service base URL, as given by the <interface>'S<accessURL>."I'm not sure what "<interface>'S<accessURL>"means, but does this sentence imply our services are no longer allowed?
Comments from TCG members during the TCG Review Period: ?? ???? 2012 - ?? ???? 2012WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice Chair ( _Christophe Arviset, Séverin Gaudet)Applications Working Group ( _Mark Taylor, Pierre Fernique)Looks good, just a few errors/queries, mostly in section 3.3.2: | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Added: | ||||||||
> > | Once those are considered, Apps recommends acceptance. -- MarkTaylor - 2012-12-07 | |||||||
Deleted: | ||||||||
< < | Once those are considered, Apps recommends acceptance. -- MarkTaylor - 2012-12-07 | |||||||
Data Access Layer Working Group ( Patrick Dowler, Mike Fitzpatrick)Data Model Working Group ( _Jesus Salgado, Omar Laurino)Grid & Web Services Working Group ( Andreas Wicenec, Andre Schaaff )Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner) | ||||||||
Added: | ||||||||
> > |
| |||||||
Semantics Working Group ( _Sebastien Derriere, Norman Gray)VOEvent Working Group ( _Matthew Graham, John Swinbank)Data Curation & Preservation Interest Group ( Alberto Accomazzi)Knowledge Discovery in Databases Interest Group ( Giuseppe Longo)Theory Interest Group ( _Herve Wozniak, Franck Le Petit)Standards and Processes Committee ( Francoise Genova)<--
|
Request for Comment: SimpleDALRegExt v1.0This document serves as the RFC center for the Proposed Recommendation entitled "Describing Simple Data Access Services, Version 1.0". The version reviewed during the RFC can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20120517/. The version revised for TCG Review can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20121116/. RFC Review period: May 23, 2012 - June 27, 2012 CompletedTCG Review period: 4 Dec 2012 - 4 Jan 2013 Exec Approved for REC: Attention TCG: if you prefer printing out a PDF version for review, consider this abbreviated version. It omits the inclusion of the appendices listing the full XML schemas, resulting in 50% fewer pages.To add a comment on 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 that 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. Additional discussion about any of the comments or responses can be conducted on the Resource 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 Notes on Implementations and ValidatersThe SimpleDALRegExt page includes several compliant sample VOResource instances that use the extension schemas defined in the spec.. Instances can be validated with an XML Schema validater such as the one provided with Junx (which is based on Xerxes). Previous versions of the extensions for ConeSearch, SIA, and SSA, which the PR versions are backward-compatible with, have been in production use by IVOA-compliant registries for several years.Comments from the communityComments from MarkTaylorA couple of comments about the schema:
Comments from TheresaDower(pardon any major formatting issues; twiki is not being kind to my preview/editing attempts) I will admit I am unsure how much this document is supposed to be an administrative collation of the existing standards and how much we intend to change each of them with an eye on backward compatibility. This may or may not be the stage at which to address inconsistencies between the standards, but I can't think of a better one. (It may also be well past time, as I note we've already gone over the RFC date but are requesting more feedback.)
Comments from Randy ThompsonComments and questions (as sent to Ray last month) * General:
"The sky coordinate axes may not particularly parallel with the image axes (e.g. due to rotation or projection effects); in this case, the longitudinal side should be considered the side of the image that it cuts the smallest angle with."Why not just define maxImageSize as the x,y dimensions in pixels of the largest image that can be requested? I suspect this is what most data providers do anyway.
"A VOResource resource description must not include both a ssap:SimpleSpectralAccess capability and a ssap:ProtoSpectralAccess capability that describe the same service base URL, as given by the <interface>'S<accessURL>."I'm not sure what "<interface>'S<accessURL>"means, but does this sentence imply our services are no longer allowed?
Comments from TCG members during the TCG Review Period: ?? ???? 2012 - ?? ???? 2012WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice Chair ( _Christophe Arviset, Séverin Gaudet)Applications Working Group ( _Mark Taylor, Pierre Fernique)Looks good, just a few errors/queries, mostly in section 3.3.2:
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Added: | ||||||||
> > |
| |||||||
Once those are considered, Apps recommends acceptance.
-- MarkTaylor - 2012-12-07
Data Access Layer Working Group ( Patrick Dowler, Mike Fitzpatrick)Data Model Working Group ( _Jesus Salgado, Omar Laurino)Grid & Web Services Working Group ( Andreas Wicenec, Andre Schaaff )Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner)Semantics Working Group ( _Sebastien Derriere, Norman Gray)VOEvent Working Group ( _Matthew Graham, John Swinbank)Data Curation & Preservation Interest Group ( Alberto Accomazzi)Knowledge Discovery in Databases Interest Group ( Giuseppe Longo)Theory Interest Group ( _Herve Wozniak, Franck Le Petit)Standards and Processes Committee ( Francoise Genova)<--
|
Request for Comment: SimpleDALRegExt v1.0This document serves as the RFC center for the Proposed Recommendation entitled "Describing Simple Data Access Services, Version 1.0". The version reviewed during the RFC can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20120517/. The version revised for TCG Review can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20121116/. RFC Review period: May 23, 2012 - June 27, 2012 CompletedTCG Review period: 4 Dec 2012 - 4 Jan 2013 Exec Approved for REC: Attention TCG: if you prefer printing out a PDF version for review, consider this abbreviated version. It omits the inclusion of the appendices listing the full XML schemas, resulting in 50% fewer pages.To add a comment on 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 that 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. Additional discussion about any of the comments or responses can be conducted on the Resource 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 Notes on Implementations and ValidatersThe SimpleDALRegExt page includes several compliant sample VOResource instances that use the extension schemas defined in the spec.. Instances can be validated with an XML Schema validater such as the one provided with Junx (which is based on Xerxes). Previous versions of the extensions for ConeSearch, SIA, and SSA, which the PR versions are backward-compatible with, have been in production use by IVOA-compliant registries for several years.Comments from the communityComments from MarkTaylorA couple of comments about the schema:
Comments from TheresaDower(pardon any major formatting issues; twiki is not being kind to my preview/editing attempts) I will admit I am unsure how much this document is supposed to be an administrative collation of the existing standards and how much we intend to change each of them with an eye on backward compatibility. This may or may not be the stage at which to address inconsistencies between the standards, but I can't think of a better one. (It may also be well past time, as I note we've already gone over the RFC date but are requesting more feedback.)
Comments from Randy ThompsonComments and questions (as sent to Ray last month) * General:
"The sky coordinate axes may not particularly parallel with the image axes (e.g. due to rotation or projection effects); in this case, the longitudinal side should be considered the side of the image that it cuts the smallest angle with."Why not just define maxImageSize as the x,y dimensions in pixels of the largest image that can be requested? I suspect this is what most data providers do anyway.
"A VOResource resource description must not include both a ssap:SimpleSpectralAccess capability and a ssap:ProtoSpectralAccess capability that describe the same service base URL, as given by the <interface>'S<accessURL>."I'm not sure what "<interface>'S<accessURL>"means, but does this sentence imply our services are no longer allowed?
Comments from TCG members during the TCG Review Period: ?? ???? 2012 - ?? ???? 2012WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice Chair ( _Christophe Arviset, Séverin Gaudet) | ||||||||
Changed: | ||||||||
< < | Applications Working Group ( _Mark Taylor, Enrique Solano) | |||||||
> > | Applications Working Group ( _Mark Taylor, Pierre Fernique) | |||||||
Added: | ||||||||
> > |
Looks good, just a few errors/queries, mostly in section 3.3.2:
| |||||||
Data Access Layer Working Group ( Patrick Dowler, Mike Fitzpatrick)Data Model Working Group ( _Jesus Salgado, Omar Laurino)Grid & Web Services Working Group ( Andreas Wicenec, Andre Schaaff )Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner)Semantics Working Group ( _Sebastien Derriere, Norman Gray)VOEvent Working Group ( _Matthew Graham, John Swinbank)Data Curation & Preservation Interest Group ( Alberto Accomazzi)Knowledge Discovery in Databases Interest Group ( Giuseppe Longo)Theory Interest Group ( _Herve Wozniak, Franck Le Petit)Standards and Processes Committee ( Francoise Genova)<--
|
Request for Comment: SimpleDALRegExt v1.0This document serves as the RFC center for the Proposed Recommendation entitled "Describing Simple Data Access Services, Version 1.0". The version reviewed during the RFC can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20120517/. The version revised for TCG Review can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20121116/. RFC Review period: May 23, 2012 - June 27, 2012 CompletedTCG Review period: 4 Dec 2012 - 4 Jan 2013 Exec Approved for REC: | ||||||||
Added: | ||||||||
> > |
Attention TCG: if you prefer printing out a PDF version for review, consider this abbreviated version. It omits the inclusion of the appendices listing the full XML schemas, resulting in 50% fewer pages. | |||||||
To add a comment on 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 that 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.
Additional discussion about any of the comments or responses can be conducted on the Resource 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
Notes on Implementations and ValidatersThe SimpleDALRegExt page includes several compliant sample VOResource instances that use the extension schemas defined in the spec.. Instances can be validated with an XML Schema validater such as the one provided with Junx (which is based on Xerxes). Previous versions of the extensions for ConeSearch, SIA, and SSA, which the PR versions are backward-compatible with, have been in production use by IVOA-compliant registries for several years.Comments from the communityComments from MarkTaylorA couple of comments about the schema:
Comments from TheresaDower(pardon any major formatting issues; twiki is not being kind to my preview/editing attempts) I will admit I am unsure how much this document is supposed to be an administrative collation of the existing standards and how much we intend to change each of them with an eye on backward compatibility. This may or may not be the stage at which to address inconsistencies between the standards, but I can't think of a better one. (It may also be well past time, as I note we've already gone over the RFC date but are requesting more feedback.)
Comments from Randy ThompsonComments and questions (as sent to Ray last month) * General:
"The sky coordinate axes may not particularly parallel with the image axes (e.g. due to rotation or projection effects); in this case, the longitudinal side should be considered the side of the image that it cuts the smallest angle with."Why not just define maxImageSize as the x,y dimensions in pixels of the largest image that can be requested? I suspect this is what most data providers do anyway.
"A VOResource resource description must not include both a ssap:SimpleSpectralAccess capability and a ssap:ProtoSpectralAccess capability that describe the same service base URL, as given by the <interface>'S<accessURL>."I'm not sure what "<interface>'S<accessURL>"means, but does this sentence imply our services are no longer allowed?
Comments from TCG members during the TCG Review Period: ?? ???? 2012 - ?? ???? 2012WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice Chair ( _Christophe Arviset, Séverin Gaudet)Applications Working Group ( _Mark Taylor, Enrique Solano)Data Access Layer Working Group ( Patrick Dowler, Mike Fitzpatrick)Data Model Working Group ( _Jesus Salgado, Omar Laurino)Grid & Web Services Working Group ( Andreas Wicenec, Andre Schaaff )Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner)Semantics Working Group ( _Sebastien Derriere, Norman Gray)VOEvent Working Group ( _Matthew Graham, John Swinbank)Data Curation & Preservation Interest Group ( Alberto Accomazzi)Knowledge Discovery in Databases Interest Group ( Giuseppe Longo)Theory Interest Group ( _Herve Wozniak, Franck Le Petit)Standards and Processes Committee ( Francoise Genova)<--
|
Changed: | ||||||||
< < | Request for Comment: SimpleDALRegExt v1.0 | |||||||
> > | Request for Comment: SimpleDALRegExt v1.0 | |||||||
Changed: | ||||||||
< < | This document serves as the RFC center for the Proposed Recommendation entitled "Describing Simple Data Access Services, Version 1.0". The version reviewed during the RFC can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20120517/. The version revised for TCG Review can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20121026/. | |||||||
> > | This document serves as the RFC center for the Proposed Recommendation entitled "Describing Simple Data Access Services, Version 1.0". The version reviewed during the RFC can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20120517/. The version revised for TCG Review can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20121116/. | |||||||
Changed: | ||||||||
< < | RFC Review period: May 23, 2012 - June 27, 2012 | |||||||
> > | RFC Review period: May 23, 2012 - June 27, 2012 Completed TCG Review period: 4 Dec 2012 - 4 Jan 2013 Exec Approved for REC: | |||||||
Deleted: | ||||||||
< < | TCG Review period: Exec Approved for REC: | |||||||
Deleted: | ||||||||
< < | Attention TCG: if you prefer printing out a PDF version for review, consider this abbreviated version. It omits the inclusion of the appendices listing the full XML schemas, resulting in 50% fewer pages. | |||||||
To add a comment on 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 that 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.
Additional discussion about any of the comments or responses can be conducted on the Resource 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
Notes on Implementations and ValidatersThe SimpleDALRegExt page includes several compliant sample VOResource instances that use the extension schemas defined in the spec.. Instances can be validated with an XML Schema validater such as the one provided with Junx (which is based on Xerxes). | ||||||||
Changed: | ||||||||
< < | Previous versions of the extensions for ConeSearch, SIA, and SSA, which the PR versions are backward-compatible with, have been in production use by IVOA-compliant registries for several years. | |||||||
> > | Previous versions of the extensions for ConeSearch, SIA, and SSA, which the PR versions are backward-compatible with, have been in production use by IVOA-compliant registries for several years. | |||||||
Comments from the community | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Comments from MarkTaylorA couple of comments about the schema: | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Deleted: | ||||||||
< < | ||||||||
And some minor comments on the text, mostly typos: | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Added: | ||||||||
> > | -- MarkTaylor - 19 Jun 2012 | |||||||
Deleted: | ||||||||
< < | -- MarkTaylor - 19 Jun 2012 | |||||||
Comments from TheresaDower | ||||||||
Added: | ||||||||
> > | ||||||||
(pardon any major formatting issues; twiki is not being kind to my preview/editing attempts) I will admit I am unsure how much this document is supposed to be an administrative collation of the existing standards and how much we intend to change each of them with an eye on backward compatibility. This may or may not be the stage at which to address inconsistencies between the standards, but I can't think of a better one. (It may also be well past time, as I note we've already gone over the RFC date but are requesting more feedback.) | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Deleted: | ||||||||
< < | ||||||||
-- TheresaDower - 23 Jul 2012 | ||||||||
Deleted: | ||||||||
< < | ||||||||
Changed: | ||||||||
< < | Comments from Randy Thompson | |||||||
> > | Comments from Randy Thompson | |||||||
Added: | ||||||||
> > | ||||||||
Comments and questions (as sent to Ray last month) * General: | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Deleted: | ||||||||
< < |
| |||||||
* SIAP: | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Deleted: | ||||||||
< < | so registering a service describing an archive of 10,000, 500 x 200 pixel images would just have an image size of 500 x 200. However the definition seems to require that the sizes be given along the axes of RA and Dec which means the orientation of the images becomes significant and the calculation more involved. Plus the orientation may vary from image to image making the definition more confusing. For example, if the orientation for the above image archive can vary such that the long axes is parallel to the RA axis in one observation and parallel to the Dec axes in another, what is the value of maxImageSize? Related to this, it might help to reword this sentence in 3.2.2.2: | |||||||
"The sky coordinate axes may not particularly parallel with the image axes (e.g. due to rotation or projection effects); in this case, the longitudinal side should be considered the side of the image that it cuts the smallest angle with." | ||||||||
Changed: | ||||||||
< < | Why not just define maxImageSize as the x,y dimensions in pixels of the largest image that can be requested? I suspect this is what most data providers do anyway. | |||||||
> > | Why not just define maxImageSize as the x,y dimensions in pixels of the largest image that can be requested? I suspect this is what most data providers do anyway.
| |||||||
Deleted: | ||||||||
< < |
| |||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Deleted: | ||||||||
< < | certainly make sense if galactic or ecliptic coordinates were allowed,
but if RA and Dec are required, why not call them RA and Dec?
| |||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Deleted: | ||||||||
< < | the SIAP document (section 6.2). I believe these have never been
enforced in the VAO.
| |||||||
* SSAP: | ||||||||
Changed: | ||||||||
< < | * supportedFrame 3.3.2 - this is listed as required, but I don't recall
seeing it used in any registered services. Perhaps it is considered
optional if only ICRS is supported?
| |||||||
> > | * supportedFrame 3.3.2 - this is listed as required, but I don't recall seeing it used in any registered services. Perhaps it is considered optional if only ICRS is supported?
| |||||||
Changed: | ||||||||
< < | * ProtoSpectralAccess 3.3.3 - We have several registered services supporting | |||||||
> > | "A VOResource resource description must not include both a | |||||||
Deleted: | ||||||||
< < | both SSAP V1.0 and its predecessor (frequently referred to as version 0.4).
We list them under separate capabilities within one resource as was discussed
with VO staff a few years ago. In section 3.3.3 it states:
"A VOResource resource description must not include both a | |||||||
ssap:SimpleSpectralAccess capability and a
ssap:ProtoSpectralAccess capability that describe the same
service base URL, as given by the | ||||||||
Changed: | ||||||||
< < | I'm not sure what "<interface>'S<accessURL>"means, but does this sentence imply our services are no longer | |||||||
> > | I'm not sure what
"<interface>'S<accessURL>" | |||||||
Deleted: | ||||||||
< < | allowed?
| |||||||
Added: | ||||||||
> > | means, but does this sentence imply our services are no longer allowed?
| |||||||
-- RandyThompson - 05 Aug 2012 | ||||||||
Deleted: | ||||||||
< < | ||||||||
Comments from TCG members during the TCG Review Period: ?? ???? 2012 - ?? ???? 2012WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory. | ||||||||
Changed: | ||||||||
< < | TCG Chair & Vice Chair (Christophe Arviset, Séverin Gaudet) | |||||||
> > | TCG Chair & Vice Chair ( _Christophe Arviset, Séverin Gaudet) | |||||||
Added: | ||||||||
> > | Applications Working Group ( _Mark Taylor, Enrique Solano) | |||||||
Added: | ||||||||
> > | Data Access Layer Working Group ( Patrick Dowler, Mike Fitzpatrick) | |||||||
Changed: | ||||||||
< < | Applications Working Group (Mark Taylor, Enrique Solano) | |||||||
> > | Data Model Working Group ( _Jesus Salgado, Omar Laurino) | |||||||
Added: | ||||||||
> > | Grid & Web Services Working Group ( Andreas Wicenec, Andre Schaaff ) | |||||||
Changed: | ||||||||
< < | Data Access Layer Working Group (Patrick Dowler, Mike Fitzpatrick) | |||||||
> > | Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner) | |||||||
Added: | ||||||||
> > | Semantics Working Group ( _Sebastien Derriere, Norman Gray) | |||||||
Changed: | ||||||||
< < | Data Model Working Group (Jesus Salgado, Omar Laurino) | |||||||
> > | VOEvent Working Group ( _Matthew Graham, John Swinbank) | |||||||
Added: | ||||||||
> > | Data Curation & Preservation Interest Group ( Alberto Accomazzi) | |||||||
Changed: | ||||||||
< < | Grid & Web Services Working Group (Andreas Wicenec, Andre Schaaff ) | |||||||
> > | Knowledge Discovery in Databases Interest Group ( Giuseppe Longo) | |||||||
Added: | ||||||||
> > | Theory Interest Group ( _Herve Wozniak, Franck Le Petit) | |||||||
Changed: | ||||||||
< < | Registry Working Group (Gretchen Greene, Pierre Le Sidaner) | |||||||
> > | Standards and Processes Committee ( Francoise Genova) | |||||||
Changed: | ||||||||
< < | ||||||||
> > |
Request for Comment: SimpleDALRegExt v1.0 | ||||||||
Changed: | ||||||||
< < | This document serves as the RFC center for the Proposed Recommendation entitled "Describing Simple Data Access Services, Version 1.0". The specification can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20120517/. | |||||||
> > | This document serves as the RFC center for the Proposed Recommendation entitled "Describing Simple Data Access Services, Version 1.0". The version reviewed during the RFC can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20120517/. The version revised for TCG Review can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20121026/. | |||||||
RFC Review period: May 23, 2012 - June 27, 2012 TCG Review period: Exec Approved for REC: | ||||||||
Added: | ||||||||
> > | Attention TCG: if you prefer printing out a PDF version for review, consider this abbreviated version. It omits the inclusion of the appendices listing the full XML schemas, resulting in 50% fewer pages. | |||||||
Deleted: | ||||||||
< < | ||||||||
To add a comment on 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 that 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.
Additional discussion about any of the comments or responses can be conducted on the Resource 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
Notes on Implementations and ValidatersThe SimpleDALRegExt page includes several compliant sample VOResource instances that use the extension schemas defined in the spec.. Instances can be validated with an XML Schema validater such as the one provided with Junx (which is based on Xerxes). Previous versions of the extensions for ConeSearch, SIA, and SSA, which the PR versions are backward-compatible with, have been in production use by IVOA-compliant registries for several years.Comments from the communityComments from MarkTaylorA couple of comments about the schema:
Comments from TheresaDower(pardon any major formatting issues; twiki is not being kind to my preview/editing attempts) I will admit I am unsure how much this document is supposed to be an administrative collation of the existing standards and how much we intend to change each of them with an eye on backward compatibility. This may or may not be the stage at which to address inconsistencies between the standards, but I can't think of a better one. (It may also be well past time, as I note we've already gone over the RFC date but are requesting more feedback.)
Comments from Randy ThompsonComments and questions (as sent to Ray last month) * General:
"The sky coordinate axes may not particularly parallel with the image axes (e.g. due to rotation or projection effects); in this case, the longitudinal side should be considered the side of the image that it cuts the smallest angle with."Why not just define maxImageSize as the x,y dimensions in pixels of the largest image that can be requested? I suspect this is what most data providers do anyway.
"A VOResource resource description must not include both a ssap:SimpleSpectralAccess capability and a ssap:ProtoSpectralAccess capability that describe the same service base URL, as given by the <interface>'S<accessURL>."I'm not sure what "<interface>'S<accessURL>"means, but does this sentence imply our services are no longer allowed?
Comments from TCG members during the TCG Review Period: ?? ???? 2012 - ?? ???? 2012WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice Chair (Christophe Arviset, Séverin Gaudet)Applications Working Group (Mark Taylor, Enrique Solano)Data Access Layer Working Group (Patrick Dowler, Mike Fitzpatrick)Data Model Working Group (Jesus Salgado, Omar Laurino)Grid & Web Services Working Group (Andreas Wicenec, Andre Schaaff )Registry Working Group (Gretchen Greene, Pierre Le Sidaner)Semantics Working Group (Sebastien Derriere, Norman Gray)VOEvent Working Group (Matthew Graham, John Swinbank)Data Curation & Preservation Interest Group (Alberto Accomazzi)Knowledge Discovery in Databases Interest Group (Giuseppe Longo)Theory Interest Group (Herve Wozniak, Franck Le Petit)Standards and Processes Committee (Francoise Genova)<--
| ||||||||
Deleted: | ||||||||
< < | ||||||||
Request for Comment: SimpleDALRegExt v1.0This document serves as the RFC center for the Proposed Recommendation entitled "Describing Simple Data Access Services, Version 1.0". The specification can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20120517/. RFC Review period: May 23, 2012 - June 27, 2012TCG Review period: Exec Approved for REC: To add a comment on 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 that 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. Additional discussion about any of the comments or responses can be conducted on the Resource 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 Notes on Implementations and ValidatersThe SimpleDALRegExt page includes several compliant sample VOResource instances that use the extension schemas defined in the spec.. Instances can be validated with an XML Schema validater such as the one provided with Junx (which is based on Xerxes). Previous versions of the extensions for ConeSearch, SIA, and SSA, which the PR versions are backward-compatible with, have been in production use by IVOA-compliant registries for several years.Comments from the communityComments from MarkTaylorA couple of comments about the schema:
Comments from TheresaDower(pardon any major formatting issues; twiki is not being kind to my preview/editing attempts) I will admit I am unsure how much this document is supposed to be an administrative collation of the existing standards and how much we intend to change each of them with an eye on backward compatibility. This may or may not be the stage at which to address inconsistencies between the standards, but I can't think of a better one. (It may also be well past time, as I note we've already gone over the RFC date but are requesting more feedback.)
Comments from Randy ThompsonComments and questions (as sent to Ray last month) * General:
"The sky coordinate axes may not particularly parallel with the image axes (e.g. due to rotation or projection effects); in this case, the longitudinal side should be considered the side of the image that it cuts the smallest angle with."Why not just define maxImageSize as the x,y dimensions in pixels of the largest image that can be requested? I suspect this is what most data providers do anyway.
"A VOResource resource description must not include both a ssap:SimpleSpectralAccess capability and a ssap:ProtoSpectralAccess capability that describe the same service base URL, as given by the <interface>'S<accessURL>."I'm not sure what "<interface>'S<accessURL>"means, but does this sentence imply our services are no longer allowed? | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
-- RandyThompson - 05 Aug 2012
Comments from TCG members during the TCG Review Period: ?? ???? 2012 - ?? ???? 2012WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice Chair (Christophe Arviset, Séverin Gaudet)Applications Working Group (Mark Taylor, Enrique Solano)Data Access Layer Working Group (Patrick Dowler, Mike Fitzpatrick)Data Model Working Group (Jesus Salgado, Omar Laurino)Grid & Web Services Working Group (Andreas Wicenec, Andre Schaaff )Registry Working Group (Gretchen Greene, Pierre Le Sidaner)Semantics Working Group (Sebastien Derriere, Norman Gray)VOEvent Working Group (Matthew Graham, John Swinbank)Data Curation & Preservation Interest Group (Alberto Accomazzi)Knowledge Discovery in Databases Interest Group (Giuseppe Longo)Theory Interest Group (Herve Wozniak, Franck Le Petit)Standards and Processes Committee (Francoise Genova)<--
|
Request for Comment: SimpleDALRegExt v1.0This document serves as the RFC center for the Proposed Recommendation entitled "Describing Simple Data Access Services, Version 1.0". The specification can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20120517/. RFC Review period: May 23, 2012 - June 27, 2012TCG Review period: Exec Approved for REC: To add a comment on 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 that 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. Additional discussion about any of the comments or responses can be conducted on the Resource 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 Notes on Implementations and ValidatersThe SimpleDALRegExt page includes several compliant sample VOResource instances that use the extension schemas defined in the spec.. Instances can be validated with an XML Schema validater such as the one provided with Junx (which is based on Xerxes). Previous versions of the extensions for ConeSearch, SIA, and SSA, which the PR versions are backward-compatible with, have been in production use by IVOA-compliant registries for several years.Comments from the communityComments from MarkTaylorA couple of comments about the schema:
Comments from TheresaDower(pardon any major formatting issues; twiki is not being kind to my preview/editing attempts) I will admit I am unsure how much this document is supposed to be an administrative collation of the existing standards and how much we intend to change each of them with an eye on backward compatibility. This may or may not be the stage at which to address inconsistencies between the standards, but I can't think of a better one. (It may also be well past time, as I note we've already gone over the RFC date but are requesting more feedback.)
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Comments from Randy ThompsonComments and questions (as sent to Ray last month) * General:
"The sky coordinate axes may not particularly parallel with the image axes (e.g. due to rotation or projection effects); in this case, the longitudinal side should be considered the side of the image that it cuts the smallest angle with."Why not just define maxImageSize as the x,y dimensions in pixels of the largest image that can be requested? I suspect this is what most data providers do anyway.
"A VOResource resource description must not include both a ssap:SimpleSpectralAccess capability and a ssap:ProtoSpectralAccess capability that describe the same service base URL, as given by the <interface>'S<accessURL>."I'm not sure what "<interface>'S<accessURL>"means, but does this sentence imply our services are no longer allowed?
Comments from TCG members during the TCG Review Period: ?? ???? 2012 - ?? ???? 2012WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice Chair (Christophe Arviset, Séverin Gaudet)Applications Working Group (Mark Taylor, Enrique Solano)Data Access Layer Working Group (Patrick Dowler, Mike Fitzpatrick)Data Model Working Group (Jesus Salgado, Omar Laurino)Grid & Web Services Working Group (Andreas Wicenec, Andre Schaaff )Registry Working Group (Gretchen Greene, Pierre Le Sidaner)Semantics Working Group (Sebastien Derriere, Norman Gray)VOEvent Working Group (Matthew Graham, John Swinbank)Data Curation & Preservation Interest Group (Alberto Accomazzi)Knowledge Discovery in Databases Interest Group (Giuseppe Longo)Theory Interest Group (Herve Wozniak, Franck Le Petit)Standards and Processes Committee (Francoise Genova)<--
|
Request for Comment: SimpleDALRegExt v1.0This document serves as the RFC center for the Proposed Recommendation entitled "Describing Simple Data Access Services, Version 1.0". The specification can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20120517/. RFC Review period: May 23, 2012 - June 27, 2012TCG Review period: Exec Approved for REC: To add a comment on 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 that 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. Additional discussion about any of the comments or responses can be conducted on the Resource 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 Notes on Implementations and ValidatersThe SimpleDALRegExt page includes several compliant sample VOResource instances that use the extension schemas defined in the spec.. Instances can be validated with an XML Schema validater such as the one provided with Junx (which is based on Xerxes). Previous versions of the extensions for ConeSearch, SIA, and SSA, which the PR versions are backward-compatible with, have been in production use by IVOA-compliant registries for several years.Comments from the communityComments from MarkTaylorA couple of comments about the schema:
Comments from TheresaDower(pardon any major formatting issues; twiki is not being kind to my preview/editing attempts) I will admit I am unsure how much this document is supposed to be an administrative collation of the existing standards and how much we intend to change each of them with an eye on backward compatibility. This may or may not be the stage at which to address inconsistencies between the standards, but I can't think of a better one. (It may also be well past time, as I note we've already gone over the RFC date but are requesting more feedback.)
Comments from Randy ThompsonComments and questions (as sent to Ray last month) * General:
"The sky coordinate axes may not particularly parallel with the image axes (e.g. due to rotation or projection effects); in this case, the longitudinal side should be considered the side of the image that it cuts the smallest angle with."Why not just define maxImageSize as the x,y dimensions in pixels of the largest image that can be requested? I suspect this is what most data providers do anyway. | ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
* SSAP: * supportedFrame 3.3.2 - this is listed as required, but I don't recall seeing it used in any registered services. Perhaps it is considered optional if only ICRS is supported? | ||||||||
Added: | ||||||||
> > |
| |||||||
* ProtoSpectralAccess 3.3.3 - We have several registered services supporting
both SSAP V1.0 and its predecessor (frequently referred to as version 0.4).
We list them under separate capabilities within one resource as was discussed
with VO staff a few years ago. In section 3.3.3 it states:
"A VOResource resource description must not include both a ssap:SimpleSpectralAccess capability and a ssap:ProtoSpectralAccess capability that describe the same service base URL, as given by the <interface>'S<accessURL>."I'm not sure what "<interface>'S<accessURL>"means, but does this sentence imply our services are no longer allowed? | ||||||||
Added: | ||||||||
> > |
| |||||||
-- RandyThompson - 05 Aug 2012
Comments from TCG members during the TCG Review Period: ?? ???? 2012 - ?? ???? 2012WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice Chair (Christophe Arviset, Séverin Gaudet)Applications Working Group (Mark Taylor, Enrique Solano)Data Access Layer Working Group (Patrick Dowler, Mike Fitzpatrick)Data Model Working Group (Jesus Salgado, Omar Laurino)Grid & Web Services Working Group (Andreas Wicenec, Andre Schaaff )Registry Working Group (Gretchen Greene, Pierre Le Sidaner)Semantics Working Group (Sebastien Derriere, Norman Gray)VOEvent Working Group (Matthew Graham, John Swinbank)Data Curation & Preservation Interest Group (Alberto Accomazzi)Knowledge Discovery in Databases Interest Group (Giuseppe Longo)Theory Interest Group (Herve Wozniak, Franck Le Petit)Standards and Processes Committee (Francoise Genova)<--
|
Request for Comment: SimpleDALRegExt v1.0This document serves as the RFC center for the Proposed Recommendation entitled "Describing Simple Data Access Services, Version 1.0". The specification can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20120517/. RFC Review period: May 23, 2012 - June 27, 2012TCG Review period: Exec Approved for REC: To add a comment on 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 that 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. Additional discussion about any of the comments or responses can be conducted on the Resource 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 Notes on Implementations and ValidatersThe SimpleDALRegExt page includes several compliant sample VOResource instances that use the extension schemas defined in the spec.. Instances can be validated with an XML Schema validater such as the one provided with Junx (which is based on Xerxes). Previous versions of the extensions for ConeSearch, SIA, and SSA, which the PR versions are backward-compatible with, have been in production use by IVOA-compliant registries for several years.Comments from the communityComments from MarkTaylorA couple of comments about the schema:
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
And some minor comments on the text, mostly typos:
| ||||||||
Added: | ||||||||
> > |
| |||||||
Added: | ||||||||
> > | ||||||||
-- MarkTaylor - 19 Jun 2012
Comments from TheresaDower(pardon any major formatting issues; twiki is not being kind to my preview/editing attempts) I will admit I am unsure how much this document is supposed to be an administrative collation of the existing standards and how much we intend to change each of them with an eye on backward compatibility. This may or may not be the stage at which to address inconsistencies between the standards, but I can't think of a better one. (It may also be well past time, as I note we've already gone over the RFC date but are requesting more feedback.) | ||||||||
Changed: | ||||||||
< < | * For example, the Cone Search test query is required. It is not required for any of the other service types. (Sec 3.2.1:) In practice, I have seen registered cone searches handle this by populating testQuery with bogus values, leading to non-responsive test queries. In practice, I've also seen validators fail non-Cone Search services 100% fullstop for having no optional testQuery. * Likewise, SSA's (Sec 3.3.2)) maxFileSize is optional, SIA's is required, and it's often populated with an intentionally meaningless value of 0. * I know there have been and continue to be good reasons for encouraging data/service providers to provide more and more metadata as the standards grow in complexity, but if there is a time to look back and make a consolidated standards document more internally consistent between standards, this is it. | |||||||
> > |
| |||||||
Added: | ||||||||
> > |
| |||||||
Deleted: | ||||||||
< < | * These comments are obviously related to MarkTaylor's general ones about the creeping number of required fields. Many of these values are difficult or impossible for service providers to calculate for some catalogs and thus many of these fields get filled with bogus information, which is less than useless to validators and client software. (If I have understood RandyThompson's offline comments correctly, Sec 3.2.2: sia:MaxImageSize/Extent stand out as a particularly difficult example for large catalogs with variably rotated images from different instruments.) Even if we don't want to tackle every field in each standard right now, it would be good to look at some of these and either make them optional or provide guideline default values in more cases than we already do. | |||||||
-- TheresaDower - 23 Jul 2012
Comments from Randy ThompsonComments and questions (as sent to Ray last month) * General:
| ||||||||
Added: | ||||||||
> > |
| |||||||
Added: | ||||||||
> > | ||||||||
* SIAP: | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Deleted: | ||||||||
< < | I guess this is really a SIAP document issue. | |||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
"The sky coordinate axes may not particularly parallel with the image axes (e.g. due to rotation or projection effects); in this case, the longitudinal side should be considered the side of the image that it cuts the smallest angle with."Why not just define maxImageSize as the x,y dimensions in pixels of the largest image that can be requested? I suspect this is what most data providers do anyway.
"A VOResource resource description must not include both a ssap:SimpleSpectralAccess capability and a ssap:ProtoSpectralAccess capability that describe the same service base URL, as given by the <interface>'S<accessURL>."I'm not sure what "<interface>'S<accessURL>"means, but does this sentence imply our services are no longer allowed? -- RandyThompson - 05 Aug 2012 Comments from TCG members during the TCG Review Period: ?? ???? 2012 - ?? ???? 2012WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice Chair (Christophe Arviset, Séverin Gaudet)Applications Working Group (Mark Taylor, Enrique Solano)Data Access Layer Working Group (Patrick Dowler, Mike Fitzpatrick)Data Model Working Group (Jesus Salgado, Omar Laurino)Grid & Web Services Working Group (Andreas Wicenec, Andre Schaaff )Registry Working Group (Gretchen Greene, Pierre Le Sidaner)Semantics Working Group (Sebastien Derriere, Norman Gray)VOEvent Working Group (Matthew Graham, John Swinbank)Data Curation & Preservation Interest Group (Alberto Accomazzi)Knowledge Discovery in Databases Interest Group (Giuseppe Longo)Theory Interest Group (Herve Wozniak, Franck Le Petit)Standards and Processes Committee (Francoise Genova)<--
|
Request for Comment: SimpleDALRegExt v1.0This document serves as the RFC center for the Proposed Recommendation entitled "Describing Simple Data Access Services, Version 1.0". The specification can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20120517/. RFC Review period: May 23, 2012 - June 27, 2012TCG Review period: Exec Approved for REC: To add a comment on 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 that 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. Additional discussion about any of the comments or responses can be conducted on the Resource 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 Notes on Implementations and ValidatersThe SimpleDALRegExt page includes several compliant sample VOResource instances that use the extension schemas defined in the spec.. Instances can be validated with an XML Schema validater such as the one provided with Junx (which is based on Xerxes). Previous versions of the extensions for ConeSearch, SIA, and SSA, which the PR versions are backward-compatible with, have been in production use by IVOA-compliant registries for several years.Comments from the communityComments from MarkTaylorA couple of comments about the schema:
Comments from TheresaDower(pardon any major formatting issues; twiki is not being kind to my preview/editing attempts) I will admit I am unsure how much this document is supposed to be an administrative collation of the existing standards and how much we intend to change each of them with an eye on backward compatibility. This may or may not be the stage at which to address inconsistencies between the standards, but I can't think of a better one. (It may also be well past time, as I note we've already gone over the RFC date but are requesting more feedback.) * For example, the Cone Search test query is required. It is not required for any of the other service types. (Sec 3.2.1:) In practice, I have seen registered cone searches handle this by populating testQuery with bogus values, leading to non-responsive test queries. In practice, I've also seen validators fail non-Cone Search services 100% fullstop for having no optional testQuery. * Likewise, SSA's (Sec 3.3.2)) maxFileSize is optional, SIA's is required, and it's often populated with an intentionally meaningless value of 0. * I know there have been and continue to be good reasons for encouraging data/service providers to provide more and more metadata as the standards grow in complexity, but if there is a time to look back and make a consolidated standards document more internally consistent between standards, this is it. * These comments are obviously related to MarkTaylor's general ones about the creeping number of required fields. Many of these values are difficult or impossible for service providers to calculate for some catalogs and thus many of these fields get filled with bogus information, which is less than useless to validators and client software. (If I have understood RandyThompson's offline comments correctly, Sec 3.2.2: sia:MaxImageSize/Extent stand out as a particularly difficult example for large catalogs with variably rotated images from different instruments.) Even if we don't want to tackle every field in each standard right now, it would be good to look at some of these and either make them optional or provide guideline default values in more cases than we already do. -- TheresaDower - 23 Jul 2012 | ||||||||
Added: | ||||||||
> > |
Comments from Randy ThompsonComments and questions (as sent to Ray last month) * General:
"The sky coordinate axes may not particularly parallel with the image axes (e.g. due to rotation or projection effects); in this case, the longitudinal side should be considered the side of the image that it cuts the smallest angle with."Why not just define maxImageSize as the x,y dimensions in pixels of the largest image that can be requested? I suspect this is what most data providers do anyway.
"A VOResource resource description must not include both a ssap:SimpleSpectralAccess capability and a ssap:ProtoSpectralAccess capability that describe the same service base URL, as given by the <interface>'S<accessURL>."I'm not sure what "<interface>'S<accessURL>"means, but does this sentence imply our services are no longer allowed? -- RandyThompson - 05 Aug 2012 | |||||||
Comments from TCG members during the TCG Review Period: ?? ???? 2012 - ?? ???? 2012WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice Chair (Christophe Arviset, Séverin Gaudet)Applications Working Group (Mark Taylor, Enrique Solano)Data Access Layer Working Group (Patrick Dowler, Mike Fitzpatrick)Data Model Working Group (Jesus Salgado, Omar Laurino)Grid & Web Services Working Group (Andreas Wicenec, Andre Schaaff )Registry Working Group (Gretchen Greene, Pierre Le Sidaner)Semantics Working Group (Sebastien Derriere, Norman Gray)VOEvent Working Group (Matthew Graham, John Swinbank)Data Curation & Preservation Interest Group (Alberto Accomazzi)Knowledge Discovery in Databases Interest Group (Giuseppe Longo)Theory Interest Group (Herve Wozniak, Franck Le Petit)Standards and Processes Committee (Francoise Genova)<--
|
Request for Comment: SimpleDALRegExt v1.0 | ||||||||
Changed: | ||||||||
< < | This document serves as the RFC center for the Proposed Recommendation entitled "Describing Simple Data Access Services, Version 1.0". The specification can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20120517/. | |||||||
> > | This document serves as the RFC center for the Proposed Recommendation entitled "Describing Simple Data Access Services, Version 1.0". The specification can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20120517/. | |||||||
RFC Review period: May 23, 2012 - June 27, 2012 TCG Review period: Exec Approved for REC: To add a comment on 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 that 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. Additional discussion about any of the comments or responses can be conducted on the Resource 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 Notes on Implementations and ValidatersThe SimpleDALRegExt page includes several compliant sample VOResource instances that use the extension schemas defined in the spec.. Instances can be validated with an XML Schema validater such as the one provided with Junx (which is based on Xerxes). Previous versions of the extensions for ConeSearch, SIA, and SSA, which the PR versions are backward-compatible with, have been in production use by IVOA-compliant registries for several years.Comments from the community | ||||||||
Changed: | ||||||||
< < | ||||||||
> > | ||||||||
Comments from MarkTaylorA couple of comments about the schema: | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
And some minor comments on the text, mostly typos: | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
-- MarkTaylor - 19 Jun 2012 | ||||||||
Added: | ||||||||
> > |
Comments from TheresaDower(pardon any major formatting issues; twiki is not being kind to my preview/editing attempts) I will admit I am unsure how much this document is supposed to be an administrative collation of the existing standards and how much we intend to change each of them with an eye on backward compatibility. This may or may not be the stage at which to address inconsistencies between the standards, but I can't think of a better one. (It may also be well past time, as I note we've already gone over the RFC date but are requesting more feedback.) * For example, the Cone Search test query is required. It is not required for any of the other service types. (Sec 3.2.1:) In practice, I have seen registered cone searches handle this by populating testQuery with bogus values, leading to non-responsive test queries. In practice, I've also seen validators fail non-Cone Search services 100% fullstop for having no optional testQuery. * Likewise, SSA's (Sec 3.3.2)) maxFileSize is optional, SIA's is required, and it's often populated with an intentionally meaningless value of 0. * I know there have been and continue to be good reasons for encouraging data/service providers to provide more and more metadata as the standards grow in complexity, but if there is a time to look back and make a consolidated standards document more internally consistent between standards, this is it. * These comments are obviously related to MarkTaylor's general ones about the creeping number of required fields. Many of these values are difficult or impossible for service providers to calculate for some catalogs and thus many of these fields get filled with bogus information, which is less than useless to validators and client software. (If I have understood RandyThompson's offline comments correctly, Sec 3.2.2: sia:MaxImageSize/Extent stand out as a particularly difficult example for large catalogs with variably rotated images from different instruments.) Even if we don't want to tackle every field in each standard right now, it would be good to look at some of these and either make them optional or provide guideline default values in more cases than we already do. -- TheresaDower - 23 Jul 2012 | |||||||
Comments from TCG members during the TCG Review Period: ?? ???? 2012 - ?? ???? 2012WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice Chair (Christophe Arviset, Séverin Gaudet)Applications Working Group (Mark Taylor, Enrique Solano)Data Access Layer Working Group (Patrick Dowler, Mike Fitzpatrick)Data Model Working Group (Jesus Salgado, Omar Laurino) | ||||||||
Changed: | ||||||||
< < | Grid & Web Services Working Group (Andreas Wicenec, Andre Schaaff ) | |||||||
> > | Grid & Web Services Working Group (Andreas Wicenec, Andre Schaaff ) | |||||||
Registry Working Group (Gretchen Greene, Pierre Le Sidaner)Semantics Working Group (Sebastien Derriere, Norman Gray)VOEvent Working Group (Matthew Graham, John Swinbank)Data Curation & Preservation Interest Group (Alberto Accomazzi)Knowledge Discovery in Databases Interest Group (Giuseppe Longo)Theory Interest Group (Herve Wozniak, Franck Le Petit)Standards and Processes Committee (Francoise Genova) |
Request for Comment: SimpleDALRegExt v1.0This document serves as the RFC center for the Proposed Recommendation entitled "Describing Simple Data Access Services, Version 1.0". The specification can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20120517/. RFC Review period: May 23, 2012 - June 27, 2012TCG Review period: Exec Approved for REC: To add a comment on 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 that 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. Additional discussion about any of the comments or responses can be conducted on the Resource 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 Notes on Implementations and ValidatersThe SimpleDALRegExt page includes several compliant sample VOResource instances that use the extension schemas defined in the spec.. Instances can be validated with an XML Schema validater such as the one provided with Junx (which is based on Xerxes). Previous versions of the extensions for ConeSearch, SIA, and SSA, which the PR versions are backward-compatible with, have been in production use by IVOA-compliant registries for several years.Comments from the communityComments from MarkTaylorA couple of comments about the schema:
Comments from TCG members during the TCG Review Period: ?? ???? 2012 - ?? ???? 2012WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice Chair (Christophe Arviset, Séverin Gaudet)Applications Working Group (Mark Taylor, Enrique Solano)Data Access Layer Working Group (Patrick Dowler, Mike Fitzpatrick)Data Model Working Group (Jesus Salgado, Omar Laurino)Grid & Web Services Working Group (Andreas Wicenec, Andre Schaaff )Registry Working Group (Gretchen Greene, Pierre Le Sidaner)Semantics Working Group (Sebastien Derriere, Norman Gray)VOEvent Working Group (Matthew Graham, John Swinbank)Data Curation & Preservation Interest Group (Alberto Accomazzi)Knowledge Discovery in Databases Interest Group (Giuseppe Longo)Theory Interest Group (Herve Wozniak, Franck Le Petit)Standards and Processes Committee (Francoise Genova) |
Request for Comment: SimpleDALRegExt v1.0This document serves as the RFC center for the Proposed Recommendation entitled "Describing Simple Data Access Services, Version 1.0". The specification can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20120517/. RFC Review period: May 23, 2012 - June 27, 2012TCG Review period: Exec Approved for REC: To add a comment on 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 that 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. Additional discussion about any of the comments or responses can be conducted on the Resource 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 Notes on Implementations and ValidatersThe SimpleDALRegExt page includes several compliant sample VOResource instances that use the extension schemas defined in the spec.. Instances can be validated with an XML Schema validater such as the one provided with Junx (which is based on Xerxes). Previous versions of the extensions for ConeSearch, SIA, and SSA, which the PR versions are backward-compatible with, have been in production use by IVOA-compliant registries for several years.Comments from the community | ||||||||
Added: | ||||||||
> > | Comments from MarkTaylorA couple of comments about the schema:
| |||||||
Comments from TCG members during the TCG Review Period: ?? ???? 2012 - ?? ???? 2012WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice Chair (Christophe Arviset, Séverin Gaudet)Applications Working Group (Mark Taylor, Enrique Solano)Data Access Layer Working Group (Patrick Dowler, Mike Fitzpatrick)Data Model Working Group (Jesus Salgado, Omar Laurino)Grid & Web Services Working Group (Andreas Wicenec, Andre Schaaff )Registry Working Group (Gretchen Greene, Pierre Le Sidaner)Semantics Working Group (Sebastien Derriere, Norman Gray)VOEvent Working Group (Matthew Graham, John Swinbank)Data Curation & Preservation Interest Group (Alberto Accomazzi)Knowledge Discovery in Databases Interest Group (Giuseppe Longo)Theory Interest Group (Herve Wozniak, Franck Le Petit)Standards and Processes Committee (Francoise Genova)<--
|
Request for Comment: SimpleDALRegExt v1.0 | ||||||||
Changed: | ||||||||
< < | This document serves as the RFC center for the Proposed Recommendation entitled "Describing Simple Data Access Services, Version 1.0". The specification can be found at http://www.ivoa.net/Documents/SimpleDALRegExtRegExt/20120517/. | |||||||
> > | This document serves as the RFC center for the Proposed Recommendation entitled "Describing Simple Data Access Services, Version 1.0". The specification can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20120517/. | |||||||
Changed: | ||||||||
< < | RFC Review period: May 21, 2012 - June 25, 2012 | |||||||
> > | RFC Review period: May 23, 2012 - June 27, 2012 | |||||||
TCG Review period: Exec Approved for REC: To add a comment on 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 that 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. Additional discussion about any of the comments or responses can be conducted on the Resource 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 Notes on Implementations and ValidatersThe SimpleDALRegExt page includes several compliant sample VOResource instances that use the extension schemas defined in the spec.. Instances can be validated with an XML Schema validater such as the one provided with Junx (which is based on Xerxes). Previous versions of the extensions for ConeSearch, SIA, and SSA, which the PR versions are backward-compatible with, have been in production use by IVOA-compliant registries for several years.Comments from the communityComments from TCG members during the TCG Review Period: ?? ???? 2012 - ?? ???? 2012WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice Chair (Christophe Arviset, Séverin Gaudet)Applications Working Group (Mark Taylor, Enrique Solano)Data Access Layer Working Group (Patrick Dowler, Mike Fitzpatrick)Data Model Working Group (Jesus Salgado, Omar Laurino)Grid & Web Services Working Group (Andreas Wicenec, Andre Schaaff )Registry Working Group (Gretchen Greene, Pierre Le Sidaner)Semantics Working Group (Sebastien Derriere, Norman Gray)VOEvent Working Group (Matthew Graham, John Swinbank)Data Curation & Preservation Interest Group (Alberto Accomazzi)Knowledge Discovery in Databases Interest Group (Giuseppe Longo)Theory Interest Group (Herve Wozniak, Franck Le Petit)Standards and Processes Committee (Francoise Genova)<--
|
Request for Comment: SimpleDALRegExt v1.0This document serves as the RFC center for the Proposed Recommendation entitled "Describing Simple Data Access Services, Version 1.0". The specification can be found at http://www.ivoa.net/Documents/SimpleDALRegExtRegExt/20120517/. | ||||||||
Changed: | ||||||||
< < | RFC Review period: | |||||||
> > | RFC Review period: May 21, 2012 - June 25, 2012 | |||||||
TCG Review period: Exec Approved for REC: To add a comment on 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 that 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. Additional discussion about any of the comments or responses can be conducted on the Resource 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 Notes on Implementations and ValidatersThe SimpleDALRegExt page includes several compliant sample VOResource instances that use the extension schemas defined in the spec.. Instances can be validated with an XML Schema validater such as the one provided with Junx (which is based on Xerxes). Previous versions of the extensions for ConeSearch, SIA, and SSA, which the PR versions are backward-compatible with, have been in production use by IVOA-compliant registries for several years.Comments from the communityComments from TCG members during the TCG Review Period: ?? ???? 2012 - ?? ???? 2012WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice Chair (Christophe Arviset, Séverin Gaudet)Applications Working Group (Mark Taylor, Enrique Solano)Data Access Layer Working Group (Patrick Dowler, Mike Fitzpatrick)Data Model Working Group (Jesus Salgado, Omar Laurino)Grid & Web Services Working Group (Andreas Wicenec, Andre Schaaff )Registry Working Group (Gretchen Greene, Pierre Le Sidaner)Semantics Working Group (Sebastien Derriere, Norman Gray)VOEvent Working Group (Matthew Graham, John Swinbank)Data Curation & Preservation Interest Group (Alberto Accomazzi)Knowledge Discovery in Databases Interest Group (Giuseppe Longo)Theory Interest Group (Herve Wozniak, Franck Le Petit)Standards and Processes Committee (Francoise Genova)<--
|
Request for Comment: SimpleDALRegExt v1.0This document serves as the RFC center for the Proposed Recommendation entitled "Describing Simple Data Access Services, Version 1.0". The specification can be found at http://www.ivoa.net/Documents/SimpleDALRegExtRegExt/20120517/. RFC Review period:TCG Review period: Exec Approved for REC: To add a comment on 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 that 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. Additional discussion about any of the comments or responses can be conducted on the Resource 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 Notes on Implementations and ValidatersThe SimpleDALRegExt page includes several compliant sample VOResource instances that use the extension schemas defined in the spec.. Instances can be validated with an XML Schema validater such as the one provided with Junx (which is based on Xerxes). Previous versions of the extensions for ConeSearch, SIA, and SSA, which the PR versions are backward-compatible with, have been in production use by IVOA-compliant registries for several years.Comments from the communityComments from TCG members during the TCG Review Period: ?? ???? 2012 - ?? ???? 2012WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice Chair (Christophe Arviset, Séverin Gaudet)Applications Working Group (Mark Taylor, Enrique Solano)Data Access Layer Working Group (Patrick Dowler, Mike Fitzpatrick)Data Model Working Group (Jesus Salgado, Omar Laurino)Grid & Web Services Working Group (Andreas Wicenec, Andre Schaaff )Registry Working Group (Gretchen Greene, Pierre Le Sidaner)Semantics Working Group (Sebastien Derriere, Norman Gray)VOEvent Working Group (Matthew Graham, John Swinbank)Data Curation & Preservation Interest Group (Alberto Accomazzi)Knowledge Discovery in Databases Interest Group (Giuseppe Longo)Theory Interest Group (Herve Wozniak, Franck Le Petit)Standards and Processes Committee (Francoise Genova)<--
|