MOC 1.1 Proposed Recommendation: Request for Comments
SummaryLatest Draft: MOC 1.1 (Proposed Recommendation) The substantive differences between version 1.1 of MOC and the preceding version 1.0 are:
Reference Interoperable Implementations(Indicate here the links to at least two Reference Interoperable Implementations)
select top 100 * from rr.stc_spatial where 1=contains(point(10, 10), coverage) and 0=contains(point(20, 20), coverage)on http://dc.g-vo.org/tap. Implementations Validators
Comments Prior to Official RFC PeriodAs I was considering semantic validation cases, I noticed this sentence in section 2.3.2:"Warning: In this basic simple ASCII string format the values may be not sorted, and the MOC may be not well-formed."which seems to contradict section 2.2.3: " An encoded MOC must also be “well-formed”. To keep the canonical property of MOC, the redundant cells are not allowed and the hierarchical encoding principle must be respected. Thus it is not allowed to encode 4 sibling cells instead of their parent (only at level 0 for the 12 first diamonds). Using this simple constraint, there is one and only one way to describe a specific region and this makes the interoperability principle easy to implement."Maybe the former was just a legacy from MOC 1.0 where ASCII MOC was less formal, perhaps intended for hand-crafted MOCs not intended for serious use. With ASCII MOC now being formalized, can we remove that sentence and require that ASCII MOCs must be just as well-formed as their FITS counterparts? -- TomDonaldson - 2019-06-14 As an ASCII MOC is often written by hand (in a Web form for instance, or as an Aladin script command), it was difficult to insure that it is always well formed at this level. Is it an ASCII MOC, yes, but potentially not well formed (ex: 3/1-210) . So the tools which have to manipulate such ASCII MOCs must check before used. At the opposite, FITS MOC is always generated by a code. So there is a real interest to force it to be stored well-formed for accelerating the future reloads. That said, you right that it is a little bit inhomogeneous, and the ASCII MOCs will be used in other contexts that just for forms and scripts. So we can considere that an ASCII MOC written by hand is not - strickly speaking an ASCII MOC (not serialized in a file) - and in this consideration - extend the well-formed constraint to all serialized MOC formats (FITS & ASCII) by just removing the sentence. -- PierreFernique - 2019-06-18 Tom answer 2019-06-21 That would be great. Thank you for doing that. Comments from the IVOA Community during RFC/TCG review period: 2019-06-14 - 2019-07-29The comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name 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 WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document
Comments from TCG member during the RFC/TCG Review Period: 2019-06-14 - 2019-07-29WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupMOC specification changes to bring String serialization to the normative part looks a good addition to this standard. The document itself is fine in general. I have two small things I'd like to point out.
Data Model Working Group
Grid & Web Services Working GroupI support Marco suggestions and at this stage I have no further comments. Please add caption to figures and tables and reference them in the text. -- GiulianoTaffoni - 2019-09-11Registry Working GroupI would like to echo Marco's comments above, regarding simplifying the separators in serialization, and perhaps go a bit further. At best, there should be only one way to do this. I am willing to settle for consistency within a MOC using any one of those, no mix and match, with a preferred character separator suggested. -- TheresaDower - 2019-07-24See below -- PierreFernique - 2019-09-03 Semantics Working GroupThe Semantics WG doesn't see anything concerning us in the proposed changes (that otherwise sound reasonable and useful to us). The spurious indent of the rule for moc in the EBNF grammar could be removed, though. -- MarkusDemleitner - 2019-07-16Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsMostly OK, but some comments:
Standards and Processes CommitteeTCG Vote: 2019-06-14 - 2019-07-29If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
<--
|
MOC 1.1 Proposed Recommendation: Request for Comments
SummaryLatest Draft: MOC 1.1 (Proposed Recommendation) The substantive differences between version 1.1 of MOC and the preceding version 1.0 are:
Reference Interoperable Implementations(Indicate here the links to at least two Reference Interoperable Implementations)
select top 100 * from rr.stc_spatial where 1=contains(point(10, 10), coverage) and 0=contains(point(20, 20), coverage)on http://dc.g-vo.org/tap. Implementations Validators
Comments Prior to Official RFC PeriodAs I was considering semantic validation cases, I noticed this sentence in section 2.3.2:"Warning: In this basic simple ASCII string format the values may be not sorted, and the MOC may be not well-formed."which seems to contradict section 2.2.3: " An encoded MOC must also be “well-formed”. To keep the canonical property of MOC, the redundant cells are not allowed and the hierarchical encoding principle must be respected. Thus it is not allowed to encode 4 sibling cells instead of their parent (only at level 0 for the 12 first diamonds). Using this simple constraint, there is one and only one way to describe a specific region and this makes the interoperability principle easy to implement."Maybe the former was just a legacy from MOC 1.0 where ASCII MOC was less formal, perhaps intended for hand-crafted MOCs not intended for serious use. With ASCII MOC now being formalized, can we remove that sentence and require that ASCII MOCs must be just as well-formed as their FITS counterparts? -- TomDonaldson - 2019-06-14 As an ASCII MOC is often written by hand (in a Web form for instance, or as an Aladin script command), it was difficult to insure that it is always well formed at this level. Is it an ASCII MOC, yes, but potentially not well formed (ex: 3/1-210) . So the tools which have to manipulate such ASCII MOCs must check before used. At the opposite, FITS MOC is always generated by a code. So there is a real interest to force it to be stored well-formed for accelerating the future reloads. That said, you right that it is a little bit inhomogeneous, and the ASCII MOCs will be used in other contexts that just for forms and scripts. So we can considere that an ASCII MOC written by hand is not - strickly speaking an ASCII MOC (not serialized in a file) - and in this consideration - extend the well-formed constraint to all serialized MOC formats (FITS & ASCII) by just removing the sentence. -- PierreFernique - 2019-06-18 Tom answer 2019-06-21 That would be great. Thank you for doing that. Comments from the IVOA Community during RFC/TCG review period: 2019-06-14 - 2019-07-29The comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name 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 WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document
Comments from TCG member during the RFC/TCG Review Period: 2019-06-14 - 2019-07-29WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupMOC specification changes to bring String serialization to the normative part looks a good addition to this standard. The document itself is fine in general. I have two small things I'd like to point out.
Data Model Working Group
Grid & Web Services Working GroupI support Marco suggestions and at this stage I have no further comments. Please add caption to figures and tables and reference them in the text. -- GiulianoTaffoni - 2019-09-11Registry Working GroupI would like to echo Marco's comments above, regarding simplifying the separators in serialization, and perhaps go a bit further. At best, there should be only one way to do this. I am willing to settle for consistency within a MOC using any one of those, no mix and match, with a preferred character separator suggested. -- TheresaDower - 2019-07-24See below -- PierreFernique - 2019-09-03 Semantics Working GroupThe Semantics WG doesn't see anything concerning us in the proposed changes (that otherwise sound reasonable and useful to us). The spurious indent of the rule for moc in the EBNF grammar could be removed, though. -- MarkusDemleitner - 2019-07-16Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsMostly OK, but some comments:
Standards and Processes CommitteeTCG Vote: 2019-06-14 - 2019-07-29If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
<--
|
MOC 1.1 Proposed Recommendation: Request for Comments
SummaryLatest Draft: MOC 1.1 (Proposed Recommendation) The substantive differences between version 1.1 of MOC and the preceding version 1.0 are:
Reference Interoperable Implementations(Indicate here the links to at least two Reference Interoperable Implementations)
select top 100 * from rr.stc_spatial where 1=contains(point(10, 10), coverage) and 0=contains(point(20, 20), coverage)on http://dc.g-vo.org/tap. Implementations Validators
Comments Prior to Official RFC PeriodAs I was considering semantic validation cases, I noticed this sentence in section 2.3.2:"Warning: In this basic simple ASCII string format the values may be not sorted, and the MOC may be not well-formed."which seems to contradict section 2.2.3: " An encoded MOC must also be “well-formed”. To keep the canonical property of MOC, the redundant cells are not allowed and the hierarchical encoding principle must be respected. Thus it is not allowed to encode 4 sibling cells instead of their parent (only at level 0 for the 12 first diamonds). Using this simple constraint, there is one and only one way to describe a specific region and this makes the interoperability principle easy to implement."Maybe the former was just a legacy from MOC 1.0 where ASCII MOC was less formal, perhaps intended for hand-crafted MOCs not intended for serious use. With ASCII MOC now being formalized, can we remove that sentence and require that ASCII MOCs must be just as well-formed as their FITS counterparts? -- TomDonaldson - 2019-06-14 As an ASCII MOC is often written by hand (in a Web form for instance, or as an Aladin script command), it was difficult to insure that it is always well formed at this level. Is it an ASCII MOC, yes, but potentially not well formed (ex: 3/1-210) . So the tools which have to manipulate such ASCII MOCs must check before used. At the opposite, FITS MOC is always generated by a code. So there is a real interest to force it to be stored well-formed for accelerating the future reloads. That said, you right that it is a little bit inhomogeneous, and the ASCII MOCs will be used in other contexts that just for forms and scripts. So we can considere that an ASCII MOC written by hand is not - strickly speaking an ASCII MOC (not serialized in a file) - and in this consideration - extend the well-formed constraint to all serialized MOC formats (FITS & ASCII) by just removing the sentence. -- PierreFernique - 2019-06-18 Tom answer 2019-06-21 That would be great. Thank you for doing that. Comments from the IVOA Community during RFC/TCG review period: 2019-06-14 - 2019-07-29The comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name 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 WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document
Comments from TCG member during the RFC/TCG Review Period: 2019-06-14 - 2019-07-29WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupMOC specification changes to bring String serialization to the normative part looks a good addition to this standard. The document itself is fine in general. I have two small things I'd like to point out.
Data Model Working Group
Grid & Web Services Working GroupI support Marco suggestions and at this stage I have no further comments. Please add caption to figures and tables and reference them in the text. -- GiulianoTaffoni - 2019-09-11Registry Working GroupI would like to echo Marco's comments above, regarding simplifying the separators in serialization, and perhaps go a bit further. At best, there should be only one way to do this. I am willing to settle for consistency within a MOC using any one of those, no mix and match, with a preferred character separator suggested. -- TheresaDower - 2019-07-24See below -- PierreFernique - 2019-09-03 Semantics Working GroupThe Semantics WG doesn't see anything concerning us in the proposed changes (that otherwise sound reasonable and useful to us). The spurious indent of the rule for moc in the EBNF grammar could be removed, though. -- MarkusDemleitner - 2019-07-16Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsMostly OK, but some comments:
Standards and Processes CommitteeTCG Vote: 2019-06-14 - 2019-07-29If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
<--
|
MOC 1.1 Proposed Recommendation: Request for Comments
SummaryLatest Draft: MOC 1.1 (Proposed Recommendation) The substantive differences between version 1.1 of MOC and the preceding version 1.0 are:
Reference Interoperable Implementations(Indicate here the links to at least two Reference Interoperable Implementations)
select top 100 * from rr.stc_spatial where 1=contains(point(10, 10), coverage) and 0=contains(point(20, 20), coverage)on http://dc.g-vo.org/tap. Implementations Validators
Comments Prior to Official RFC PeriodAs I was considering semantic validation cases, I noticed this sentence in section 2.3.2:"Warning: In this basic simple ASCII string format the values may be not sorted, and the MOC may be not well-formed."which seems to contradict section 2.2.3: " An encoded MOC must also be “well-formed”. To keep the canonical property of MOC, the redundant cells are not allowed and the hierarchical encoding principle must be respected. Thus it is not allowed to encode 4 sibling cells instead of their parent (only at level 0 for the 12 first diamonds). Using this simple constraint, there is one and only one way to describe a specific region and this makes the interoperability principle easy to implement."Maybe the former was just a legacy from MOC 1.0 where ASCII MOC was less formal, perhaps intended for hand-crafted MOCs not intended for serious use. With ASCII MOC now being formalized, can we remove that sentence and require that ASCII MOCs must be just as well-formed as their FITS counterparts? -- TomDonaldson - 2019-06-14 As an ASCII MOC is often written by hand (in a Web form for instance, or as an Aladin script command), it was difficult to insure that it is always well formed at this level. Is it an ASCII MOC, yes, but potentially not well formed (ex: 3/1-210) . So the tools which have to manipulate such ASCII MOCs must check before used. At the opposite, FITS MOC is always generated by a code. So there is a real interest to force it to be stored well-formed for accelerating the future reloads. That said, you right that it is a little bit inhomogeneous, and the ASCII MOCs will be used in other contexts that just for forms and scripts. So we can considere that an ASCII MOC written by hand is not - strickly speaking an ASCII MOC (not serialized in a file) - and in this consideration - extend the well-formed constraint to all serialized MOC formats (FITS & ASCII) by just removing the sentence. -- PierreFernique - 2019-06-18 Tom answer 2019-06-21 That would be great. Thank you for doing that. Comments from the IVOA Community during RFC/TCG review period: 2019-06-14 - 2019-07-29The comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name 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 WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document
Comments from TCG member during the RFC/TCG Review Period: 2019-06-14 - 2019-07-29WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupMOC specification changes to bring String serialization to the normative part looks a good addition to this standard. The document itself is fine in general. I have two small things I'd like to point out.
Data Model Working Group
Grid & Web Services Working GroupI support Marco suggestions and at this stage I have no further comments. Please add caption to figures and tables and reference them in the text. -- GiulianoTaffoni - 2019-09-11Registry Working GroupI would like to echo Marco's comments above, regarding simplifying the separators in serialization, and perhaps go a bit further. At best, there should be only one way to do this. I am willing to settle for consistency within a MOC using any one of those, no mix and match, with a preferred character separator suggested. -- TheresaDower - 2019-07-24See below -- PierreFernique - 2019-09-03 Semantics Working GroupThe Semantics WG doesn't see anything concerning us in the proposed changes (that otherwise sound reasonable and useful to us). The spurious indent of the rule for moc in the EBNF grammar could be removed, though. -- MarkusDemleitner - 2019-07-16Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsMostly OK, but some comments:
Standards and Processes CommitteeTCG Vote: 2019-06-14 - 2019-07-29If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| |||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||
<--
|
MOC 1.1 Proposed Recommendation: Request for Comments
SummaryLatest Draft: MOC 1.1 (Proposed Recommendation) The substantive differences between version 1.1 of MOC and the preceding version 1.0 are:
Reference Interoperable Implementations(Indicate here the links to at least two Reference Interoperable Implementations)
select top 100 * from rr.stc_spatial where 1=contains(point(10, 10), coverage) and 0=contains(point(20, 20), coverage)on http://dc.g-vo.org/tap. Implementations Validators
Comments Prior to Official RFC PeriodAs I was considering semantic validation cases, I noticed this sentence in section 2.3.2:"Warning: In this basic simple ASCII string format the values may be not sorted, and the MOC may be not well-formed."which seems to contradict section 2.2.3: " An encoded MOC must also be “well-formed”. To keep the canonical property of MOC, the redundant cells are not allowed and the hierarchical encoding principle must be respected. Thus it is not allowed to encode 4 sibling cells instead of their parent (only at level 0 for the 12 first diamonds). Using this simple constraint, there is one and only one way to describe a specific region and this makes the interoperability principle easy to implement."Maybe the former was just a legacy from MOC 1.0 where ASCII MOC was less formal, perhaps intended for hand-crafted MOCs not intended for serious use. With ASCII MOC now being formalized, can we remove that sentence and require that ASCII MOCs must be just as well-formed as their FITS counterparts? -- TomDonaldson - 2019-06-14 As an ASCII MOC is often written by hand (in a Web form for instance, or as an Aladin script command), it was difficult to insure that it is always well formed at this level. Is it an ASCII MOC, yes, but potentially not well formed (ex: 3/1-210) . So the tools which have to manipulate such ASCII MOCs must check before used. At the opposite, FITS MOC is always generated by a code. So there is a real interest to force it to be stored well-formed for accelerating the future reloads. That said, you right that it is a little bit inhomogeneous, and the ASCII MOCs will be used in other contexts that just for forms and scripts. So we can considere that an ASCII MOC written by hand is not - strickly speaking an ASCII MOC (not serialized in a file) - and in this consideration - extend the well-formed constraint to all serialized MOC formats (FITS & ASCII) by just removing the sentence. -- PierreFernique - 2019-06-18 Tom answer 2019-06-21 That would be great. Thank you for doing that. Comments from the IVOA Community during RFC/TCG review period: 2019-06-14 - 2019-07-29The comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name 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 WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document
Comments from TCG member during the RFC/TCG Review Period: 2019-06-14 - 2019-07-29WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupMOC specification changes to bring String serialization to the normative part looks a good addition to this standard. The document itself is fine in general. I have two small things I'd like to point out.
Data Model Working Group
Grid & Web Services Working GroupI support Marco suggestions and at this stage I have no further comments. Please add caption to figures and tables and reference them in the text. -- GiulianoTaffoni - 2019-09-11Registry Working GroupI would like to echo Marco's comments above, regarding simplifying the separators in serialization, and perhaps go a bit further. At best, there should be only one way to do this. I am willing to settle for consistency within a MOC using any one of those, no mix and match, with a preferred character separator suggested. -- TheresaDower - 2019-07-24See below -- PierreFernique - 2019-09-03 Semantics Working GroupThe Semantics WG doesn't see anything concerning us in the proposed changes (that otherwise sound reasonable and useful to us). The spurious indent of the rule for moc in the EBNF grammar could be removed, though. -- MarkusDemleitner - 2019-07-16Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsMostly OK, but some comments:
Standards and Processes CommitteeTCG Vote: 2019-06-14 - 2019-07-29If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
<--
|
MOC 1.1 Proposed Recommendation: Request for Comments
SummaryLatest Draft: MOC 1.1 (Proposed Recommendation) The substantive differences between version 1.1 of MOC and the preceding version 1.0 are:
Reference Interoperable Implementations(Indicate here the links to at least two Reference Interoperable Implementations)
select top 100 * from rr.stc_spatial where 1=contains(point(10, 10), coverage) and 0=contains(point(20, 20), coverage)on http://dc.g-vo.org/tap. Implementations Validators
Comments Prior to Official RFC PeriodAs I was considering semantic validation cases, I noticed this sentence in section 2.3.2:"Warning: In this basic simple ASCII string format the values may be not sorted, and the MOC may be not well-formed."which seems to contradict section 2.2.3: " An encoded MOC must also be “well-formed”. To keep the canonical property of MOC, the redundant cells are not allowed and the hierarchical encoding principle must be respected. Thus it is not allowed to encode 4 sibling cells instead of their parent (only at level 0 for the 12 first diamonds). Using this simple constraint, there is one and only one way to describe a specific region and this makes the interoperability principle easy to implement."Maybe the former was just a legacy from MOC 1.0 where ASCII MOC was less formal, perhaps intended for hand-crafted MOCs not intended for serious use. With ASCII MOC now being formalized, can we remove that sentence and require that ASCII MOCs must be just as well-formed as their FITS counterparts? -- TomDonaldson - 2019-06-14 As an ASCII MOC is often written by hand (in a Web form for instance, or as an Aladin script command), it was difficult to insure that it is always well formed at this level. Is it an ASCII MOC, yes, but potentially not well formed (ex: 3/1-210) . So the tools which have to manipulate such ASCII MOCs must check before used. At the opposite, FITS MOC is always generated by a code. So there is a real interest to force it to be stored well-formed for accelerating the future reloads. That said, you right that it is a little bit inhomogeneous, and the ASCII MOCs will be used in other contexts that just for forms and scripts. So we can considere that an ASCII MOC written by hand is not - strickly speaking an ASCII MOC (not serialized in a file) - and in this consideration - extend the well-formed constraint to all serialized MOC formats (FITS & ASCII) by just removing the sentence. -- PierreFernique - 2019-06-18 Tom answer 2019-06-21 That would be great. Thank you for doing that. Comments from the IVOA Community during RFC/TCG review period: 2019-06-14 - 2019-07-29The comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name 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 WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document
Comments from TCG member during the RFC/TCG Review Period: 2019-06-14 - 2019-07-29WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupMOC specification changes to bring String serialization to the normative part looks a good addition to this standard. The document itself is fine in general. I have two small things I'd like to point out.
Data Model Working Group
Grid & Web Services Working GroupI support Marco suggestions and at this stage I have no further comments. Please add caption to figures and tables and reference them in the text. -- GiulianoTaffoni - 2019-09-11Registry Working GroupI would like to echo Marco's comments above, regarding simplifying the separators in serialization, and perhaps go a bit further. At best, there should be only one way to do this. I am willing to settle for consistency within a MOC using any one of those, no mix and match, with a preferred character separator suggested. -- TheresaDower - 2019-07-24See below -- PierreFernique - 2019-09-03 Semantics Working GroupThe Semantics WG doesn't see anything concerning us in the proposed changes (that otherwise sound reasonable and useful to us). The spurious indent of the rule for moc in the EBNF grammar could be removed, though. -- MarkusDemleitner - 2019-07-16Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsMostly OK, but some comments:
Standards and Processes CommitteeTCG Vote: 2019-06-14 - 2019-07-29If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
<--
|
MOC 1.1 Proposed Recommendation: Request for Comments
SummaryLatest Draft: MOC 1.1 (Proposed Recommendation) The substantive differences between version 1.1 of MOC and the preceding version 1.0 are:
Reference Interoperable Implementations(Indicate here the links to at least two Reference Interoperable Implementations)
select top 100 * from rr.stc_spatial where 1=contains(point(10, 10), coverage) and 0=contains(point(20, 20), coverage)on http://dc.g-vo.org/tap. Implementations Validators
Comments Prior to Official RFC PeriodAs I was considering semantic validation cases, I noticed this sentence in section 2.3.2:"Warning: In this basic simple ASCII string format the values may be not sorted, and the MOC may be not well-formed."which seems to contradict section 2.2.3: " An encoded MOC must also be “well-formed”. To keep the canonical property of MOC, the redundant cells are not allowed and the hierarchical encoding principle must be respected. Thus it is not allowed to encode 4 sibling cells instead of their parent (only at level 0 for the 12 first diamonds). Using this simple constraint, there is one and only one way to describe a specific region and this makes the interoperability principle easy to implement."Maybe the former was just a legacy from MOC 1.0 where ASCII MOC was less formal, perhaps intended for hand-crafted MOCs not intended for serious use. With ASCII MOC now being formalized, can we remove that sentence and require that ASCII MOCs must be just as well-formed as their FITS counterparts? -- TomDonaldson - 2019-06-14 As an ASCII MOC is often written by hand (in a Web form for instance, or as an Aladin script command), it was difficult to insure that it is always well formed at this level. Is it an ASCII MOC, yes, but potentially not well formed (ex: 3/1-210) . So the tools which have to manipulate such ASCII MOCs must check before used. At the opposite, FITS MOC is always generated by a code. So there is a real interest to force it to be stored well-formed for accelerating the future reloads. That said, you right that it is a little bit inhomogeneous, and the ASCII MOCs will be used in other contexts that just for forms and scripts. So we can considere that an ASCII MOC written by hand is not - strickly speaking an ASCII MOC (not serialized in a file) - and in this consideration - extend the well-formed constraint to all serialized MOC formats (FITS & ASCII) by just removing the sentence. -- PierreFernique - 2019-06-18 Tom answer 2019-06-21 That would be great. Thank you for doing that. Comments from the IVOA Community during RFC/TCG review period: 2019-06-14 - 2019-07-29The comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name 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 WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document
Comments from TCG member during the RFC/TCG Review Period: 2019-06-14 - 2019-07-29WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupMOC specification changes to bring String serialization to the normative part looks a good addition to this standard. The document itself is fine in general. I have two small things I'd like to point out.
Data Model Working Group
Grid & Web Services Working GroupI support Marco suggestions and at this stage I have no further comments. Please add caption to figures and tables and reference them in the text. -- GiulianoTaffoni - 2019-09-11Registry Working GroupI would like to echo Marco's comments above, regarding simplifying the separators in serialization, and perhaps go a bit further. At best, there should be only one way to do this. I am willing to settle for consistency within a MOC using any one of those, no mix and match, with a preferred character separator suggested. -- TheresaDower - 2019-07-24See below -- PierreFernique - 2019-09-03 Semantics Working GroupThe Semantics WG doesn't see anything concerning us in the proposed changes (that otherwise sound reasonable and useful to us). The spurious indent of the rule for moc in the EBNF grammar could be removed, though. -- MarkusDemleitner - 2019-07-16Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsMostly OK, but some comments:
Standards and Processes CommitteeTCG Vote: 2019-06-14 - 2019-07-29If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
<--
|
MOC 1.1 Proposed Recommendation: Request for Comments
SummaryLatest Draft: MOC 1.1 (Proposed Recommendation) The substantive differences between version 1.1 of MOC and the preceding version 1.0 are:
Reference Interoperable Implementations(Indicate here the links to at least two Reference Interoperable Implementations)
select top 100 * from rr.stc_spatial where 1=contains(point(10, 10), coverage) and 0=contains(point(20, 20), coverage)on http://dc.g-vo.org/tap. Implementations Validators
Comments Prior to Official RFC PeriodAs I was considering semantic validation cases, I noticed this sentence in section 2.3.2:"Warning: In this basic simple ASCII string format the values may be not sorted, and the MOC may be not well-formed."which seems to contradict section 2.2.3: " An encoded MOC must also be “well-formed”. To keep the canonical property of MOC, the redundant cells are not allowed and the hierarchical encoding principle must be respected. Thus it is not allowed to encode 4 sibling cells instead of their parent (only at level 0 for the 12 first diamonds). Using this simple constraint, there is one and only one way to describe a specific region and this makes the interoperability principle easy to implement."Maybe the former was just a legacy from MOC 1.0 where ASCII MOC was less formal, perhaps intended for hand-crafted MOCs not intended for serious use. With ASCII MOC now being formalized, can we remove that sentence and require that ASCII MOCs must be just as well-formed as their FITS counterparts? -- TomDonaldson - 2019-06-14 As an ASCII MOC is often written by hand (in a Web form for instance, or as an Aladin script command), it was difficult to insure that it is always well formed at this level. Is it an ASCII MOC, yes, but potentially not well formed (ex: 3/1-210) . So the tools which have to manipulate such ASCII MOCs must check before used. At the opposite, FITS MOC is always generated by a code. So there is a real interest to force it to be stored well-formed for accelerating the future reloads. That said, you right that it is a little bit inhomogeneous, and the ASCII MOCs will be used in other contexts that just for forms and scripts. So we can considere that an ASCII MOC written by hand is not - strickly speaking an ASCII MOC (not serialized in a file) - and in this consideration - extend the well-formed constraint to all serialized MOC formats (FITS & ASCII) by just removing the sentence. -- PierreFernique - 2019-06-18 Tom answer 2019-06-21 That would be great. Thank you for doing that. Comments from the IVOA Community during RFC/TCG review period: 2019-06-14 - 2019-07-29The comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name 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 WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document
Comments from TCG member during the RFC/TCG Review Period: 2019-06-14 - 2019-07-29WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupMOC specification changes to bring String serialization to the normative part looks a good addition to this standard. The document itself is fine in general. I have two small things I'd like to point out.
Data Model Working Group
Grid & Web Services Working Group | ||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||
> > | I support Marco suggestions and at this stage I have no further comments. Please add caption to figures and tables and reference them in the text. -- GiulianoTaffoni - 2019-09-11 | |||||||||||||||||||||||||||||||||||||||||||||||
Registry Working GroupI would like to echo Marco's comments above, regarding simplifying the separators in serialization, and perhaps go a bit further. At best, there should be only one way to do this. I am willing to settle for consistency within a MOC using any one of those, no mix and match, with a preferred character separator suggested. -- TheresaDower - 2019-07-24See below -- PierreFernique - 2019-09-03 Semantics Working GroupThe Semantics WG doesn't see anything concerning us in the proposed changes (that otherwise sound reasonable and useful to us). The spurious indent of the rule for moc in the EBNF grammar could be removed, though. -- MarkusDemleitner - 2019-07-16Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsMostly OK, but some comments:
Standards and Processes CommitteeTCG Vote: 2019-06-14 - 2019-07-29If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| ||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||
<--
|
MOC 1.1 Proposed Recommendation: Request for Comments
SummaryLatest Draft: MOC 1.1 (Proposed Recommendation) The substantive differences between version 1.1 of MOC and the preceding version 1.0 are:
Reference Interoperable Implementations(Indicate here the links to at least two Reference Interoperable Implementations)
select top 100 * from rr.stc_spatial where 1=contains(point(10, 10), coverage) and 0=contains(point(20, 20), coverage)on http://dc.g-vo.org/tap. Implementations Validators
Comments Prior to Official RFC PeriodAs I was considering semantic validation cases, I noticed this sentence in section 2.3.2:"Warning: In this basic simple ASCII string format the values may be not sorted, and the MOC may be not well-formed."which seems to contradict section 2.2.3: " An encoded MOC must also be “well-formed”. To keep the canonical property of MOC, the redundant cells are not allowed and the hierarchical encoding principle must be respected. Thus it is not allowed to encode 4 sibling cells instead of their parent (only at level 0 for the 12 first diamonds). Using this simple constraint, there is one and only one way to describe a specific region and this makes the interoperability principle easy to implement."Maybe the former was just a legacy from MOC 1.0 where ASCII MOC was less formal, perhaps intended for hand-crafted MOCs not intended for serious use. With ASCII MOC now being formalized, can we remove that sentence and require that ASCII MOCs must be just as well-formed as their FITS counterparts? -- TomDonaldson - 2019-06-14 As an ASCII MOC is often written by hand (in a Web form for instance, or as an Aladin script command), it was difficult to insure that it is always well formed at this level. Is it an ASCII MOC, yes, but potentially not well formed (ex: 3/1-210) . So the tools which have to manipulate such ASCII MOCs must check before used. At the opposite, FITS MOC is always generated by a code. So there is a real interest to force it to be stored well-formed for accelerating the future reloads. That said, you right that it is a little bit inhomogeneous, and the ASCII MOCs will be used in other contexts that just for forms and scripts. So we can considere that an ASCII MOC written by hand is not - strickly speaking an ASCII MOC (not serialized in a file) - and in this consideration - extend the well-formed constraint to all serialized MOC formats (FITS & ASCII) by just removing the sentence. -- PierreFernique - 2019-06-18 Tom answer 2019-06-21 That would be great. Thank you for doing that. Comments from the IVOA Community during RFC/TCG review period: 2019-06-14 - 2019-07-29The comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name 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 WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document
Comments from TCG member during the RFC/TCG Review Period: 2019-06-14 - 2019-07-29WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupMOC specification changes to bring String serialization to the normative part looks a good addition to this standard. The document itself is fine in general. I have two small things I'd like to point out. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-- MarcoMolinaro - 2019-07-11
Data Model Working Group
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-- LaurentMichel - 2019-07-25
Grid & Web Services Working GroupRegistry Working GroupI would like to echo Marco's comments above, regarding simplifying the separators in serialization, and perhaps go a bit further. At best, there should be only one way to do this. I am willing to settle for consistency within a MOC using any one of those, no mix and match, with a preferred character separator suggested. -- TheresaDower - 2019-07-24See below -- PierreFernique - 2019-09-03 Semantics Working GroupThe Semantics WG doesn't see anything concerning us in the proposed changes (that otherwise sound reasonable and useful to us). The spurious indent of the rule for moc in the EBNF grammar could be removed, though. -- MarkusDemleitner - 2019-07-16Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsMostly OK, but some comments: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-- MarkTaylor - 2019-07-13
Standards and Processes CommitteeTCG Vote: 2019-06-14 - 2019-07-29If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
<--
|
MOC 1.1 Proposed Recommendation: Request for Comments
SummaryLatest Draft: MOC 1.1 (Proposed Recommendation) The substantive differences between version 1.1 of MOC and the preceding version 1.0 are:
Reference Interoperable Implementations(Indicate here the links to at least two Reference Interoperable Implementations)
select top 100 * from rr.stc_spatial where 1=contains(point(10, 10), coverage) and 0=contains(point(20, 20), coverage)on http://dc.g-vo.org/tap. Implementations Validators
Comments Prior to Official RFC PeriodAs I was considering semantic validation cases, I noticed this sentence in section 2.3.2:"Warning: In this basic simple ASCII string format the values may be not sorted, and the MOC may be not well-formed."which seems to contradict section 2.2.3: " An encoded MOC must also be “well-formed”. To keep the canonical property of MOC, the redundant cells are not allowed and the hierarchical encoding principle must be respected. Thus it is not allowed to encode 4 sibling cells instead of their parent (only at level 0 for the 12 first diamonds). Using this simple constraint, there is one and only one way to describe a specific region and this makes the interoperability principle easy to implement."Maybe the former was just a legacy from MOC 1.0 where ASCII MOC was less formal, perhaps intended for hand-crafted MOCs not intended for serious use. With ASCII MOC now being formalized, can we remove that sentence and require that ASCII MOCs must be just as well-formed as their FITS counterparts? -- TomDonaldson - 2019-06-14 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | As an ASCII MOC is often written by hand (in a Web form for instance, or as an Aladin script command), it was difficult to insure that it is always well formed at this level. Is it an ASCII MOC, yes, but potentially not well formed (ex: 3/1-210) . So the tools which have to manipulate such ASCII MOCs must check before used. At the opposite, FITS MOC is always generated by a code. So there is a real interest to force it to be stored well-formed for accelerating the future reloads. That said, you right that it is a little bit inhomogeneous, and the ASCII MOCs will be used in other contexts that just for forms and scripts. So we can considere that an ASCII MOC written by hand is not - strickly speaking an ASCII MOC (not serialized in a file) - and in this consideration - extend the well-formed constraint to all serialized MOC formats (FITS & ASCII) by just removing the sentence. -- PierreFernique - 2019-06-18 Tom answer 2019-06-21 That would be great. Thank you for doing that. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Comments from the IVOA Community during RFC/TCG review period: 2019-06-14 - 2019-07-29The comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name 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 WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Comments from TCG member during the RFC/TCG Review Period: 2019-06-14 - 2019-07-29WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupMOC specification changes to bring String serialization to the normative part looks a good addition to this standard. The document itself is fine in general. I have two small things I'd like to point out. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-- MarcoMolinaro - 2019-07-11
Data Model Working Group | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-- LaurentMichel - 2019-07-25
Grid & Web Services Working GroupRegistry Working Group | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | I would like to echo Marco's comments above, regarding simplifying the separators in serialization, and perhaps go a bit further. At best, there should be only one way to do this. I am willing to settle for consistency within a MOC using any one of those, no mix and match, with a preferred character separator suggested. -- TheresaDower - 2019-07-24 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | I would like to echo Marco's comments above, regarding simplifying the separators in serialization, and perhaps go a bit further. At best, there should be only one way to do this. I am willing to settle for consistency within a MOC using any one of those, no mix and match, with a preferred character separator suggested. -- TheresaDower - 2019-07-24 See below -- PierreFernique - 2019-09-03 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Semantics Working GroupThe Semantics WG doesn't see anything concerning us in the proposed changes (that otherwise sound reasonable and useful to us). The spurious indent of the rule for moc in the EBNF grammar could be removed, though. -- MarkusDemleitner - 2019-07-16Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsMostly OK, but some comments: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Standards and Processes CommitteeTCG Vote: 2019-06-14 - 2019-07-29If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
<--
|
MOC 1.1 Proposed Recommendation: Request for Comments
SummaryLatest Draft: MOC 1.1 (Proposed Recommendation) The substantive differences between version 1.1 of MOC and the preceding version 1.0 are:
Reference Interoperable Implementations(Indicate here the links to at least two Reference Interoperable Implementations)
select top 100 * from rr.stc_spatial where 1=contains(point(10, 10), coverage) and 0=contains(point(20, 20), coverage)on http://dc.g-vo.org/tap. Implementations Validators
Comments Prior to Official RFC PeriodAs I was considering semantic validation cases, I noticed this sentence in section 2.3.2:"Warning: In this basic simple ASCII string format the values may be not sorted, and the MOC may be not well-formed."which seems to contradict section 2.2.3: " An encoded MOC must also be “well-formed”. To keep the canonical property of MOC, the redundant cells are not allowed and the hierarchical encoding principle must be respected. Thus it is not allowed to encode 4 sibling cells instead of their parent (only at level 0 for the 12 first diamonds). Using this simple constraint, there is one and only one way to describe a specific region and this makes the interoperability principle easy to implement."Maybe the former was just a legacy from MOC 1.0 where ASCII MOC was less formal, perhaps intended for hand-crafted MOCs not intended for serious use. With ASCII MOC now being formalized, can we remove that sentence and require that ASCII MOCs must be just as well-formed as their FITS counterparts? -- TomDonaldson - 2019-06-14 Comments from the IVOA Community during RFC/TCG review period: 2019-06-14 - 2019-07-29The comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name 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 WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document
Comments from TCG member during the RFC/TCG Review Period: 2019-06-14 - 2019-07-29WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupMOC specification changes to bring String serialization to the normative part looks a good addition to this standard. The document itself is fine in general. I have two small things I'd like to point out.
Data Model Working Group | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Grid & Web Services Working GroupRegistry Working GroupI would like to echo Marco's comments above, regarding simplifying the separators in serialization, and perhaps go a bit further. At best, there should be only one way to do this. I am willing to settle for consistency within a MOC using any one of those, no mix and match, with a preferred character separator suggested. -- TheresaDower - 2019-07-24Semantics Working GroupThe Semantics WG doesn't see anything concerning us in the proposed changes (that otherwise sound reasonable and useful to us). The spurious indent of the rule for moc in the EBNF grammar could be removed, though. -- MarkusDemleitner - 2019-07-16Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsMostly OK, but some comments:
Standards and Processes CommitteeTCG Vote: 2019-06-14 - 2019-07-29If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
<--
|
MOC 1.1 Proposed Recommendation: Request for Comments
SummaryLatest Draft: MOC 1.1 (Proposed Recommendation) The substantive differences between version 1.1 of MOC and the preceding version 1.0 are:
Reference Interoperable Implementations(Indicate here the links to at least two Reference Interoperable Implementations)
select top 100 * from rr.stc_spatial where 1=contains(point(10, 10), coverage) and 0=contains(point(20, 20), coverage)on http://dc.g-vo.org/tap. Implementations Validators
Comments Prior to Official RFC PeriodAs I was considering semantic validation cases, I noticed this sentence in section 2.3.2:"Warning: In this basic simple ASCII string format the values may be not sorted, and the MOC may be not well-formed."which seems to contradict section 2.2.3: " An encoded MOC must also be “well-formed”. To keep the canonical property of MOC, the redundant cells are not allowed and the hierarchical encoding principle must be respected. Thus it is not allowed to encode 4 sibling cells instead of their parent (only at level 0 for the 12 first diamonds). Using this simple constraint, there is one and only one way to describe a specific region and this makes the interoperability principle easy to implement."Maybe the former was just a legacy from MOC 1.0 where ASCII MOC was less formal, perhaps intended for hand-crafted MOCs not intended for serious use. With ASCII MOC now being formalized, can we remove that sentence and require that ASCII MOCs must be just as well-formed as their FITS counterparts? -- TomDonaldson - 2019-06-14 Comments from the IVOA Community during RFC/TCG review period: 2019-06-14 - 2019-07-29The comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name 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 WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document
Comments from TCG member during the RFC/TCG Review Period: 2019-06-14 - 2019-07-29WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupMOC specification changes to bring String serialization to the normative part looks a good addition to this standard. The document itself is fine in general. I have two small things I'd like to point out.
Data Model Working GroupGrid & Web Services Working GroupRegistry Working Group | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | I would like to echo Marco's comments above, regarding simplifying the separators in serialization, and perhaps go a bit further. At best, there should be only one way to do this. I am willing to settle for consistency within a MOC using any one of those, no mix and match, with a preferred character separator suggested. -- TheresaDower - 2019-07-24 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Semantics Working Group | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | The Semantics WG doesn't see anything concerning us in the proposed | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | The Semantics WG doesn't see anything concerning us in the proposed changes (that otherwise sound reasonable and useful to us). The spurious indent of the rule for moc in the EBNF grammar could be removed, though. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | changes (that otherwise sound reasonable and useful to us). The spurious indent of the rule for moc in the EBNF grammar could be removed, though. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-- MarkusDemleitner - 2019-07-16
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsMostly OK, but some comments:
Standards and Processes CommitteeTCG Vote: 2019-06-14 - 2019-07-29If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
<--
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
MOC 1.1 Proposed Recommendation: Request for Comments
SummaryLatest Draft: MOC 1.1 (Proposed Recommendation) The substantive differences between version 1.1 of MOC and the preceding version 1.0 are:
Reference Interoperable Implementations(Indicate here the links to at least two Reference Interoperable Implementations)
select top 100 * from rr.stc_spatial where 1=contains(point(10, 10), coverage) and 0=contains(point(20, 20), coverage)on http://dc.g-vo.org/tap. Implementations Validators
Comments Prior to Official RFC PeriodAs I was considering semantic validation cases, I noticed this sentence in section 2.3.2:"Warning: In this basic simple ASCII string format the values may be not sorted, and the MOC may be not well-formed."which seems to contradict section 2.2.3: " An encoded MOC must also be “well-formed”. To keep the canonical property of MOC, the redundant cells are not allowed and the hierarchical encoding principle must be respected. Thus it is not allowed to encode 4 sibling cells instead of their parent (only at level 0 for the 12 first diamonds). Using this simple constraint, there is one and only one way to describe a specific region and this makes the interoperability principle easy to implement."Maybe the former was just a legacy from MOC 1.0 where ASCII MOC was less formal, perhaps intended for hand-crafted MOCs not intended for serious use. With ASCII MOC now being formalized, can we remove that sentence and require that ASCII MOCs must be just as well-formed as their FITS counterparts? -- TomDonaldson - 2019-06-14 Comments from the IVOA Community during RFC/TCG review period: 2019-06-14 - 2019-07-29The comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name 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 WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document
Comments from TCG member during the RFC/TCG Review Period: 2019-06-14 - 2019-07-29WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupMOC specification changes to bring String serialization to the normative part looks a good addition to this standard. The document itself is fine in general. I have two small things I'd like to point out.
Data Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working GroupThe Semantics WG doesn't see anything concerning us in the proposed changes (that otherwise sound reasonable and useful to us). The spurious indent of the rule for moc in the EBNF grammar could be removed, though. -- MarkusDemleitner - 2019-07-16Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsMostly OK, but some comments:
Standards and Processes CommitteeTCG Vote: 2019-06-14 - 2019-07-29If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
<--
|
MOC 1.1 Proposed Recommendation: Request for Comments
SummaryLatest Draft: MOC 1.1 (Proposed Recommendation) The substantive differences between version 1.1 of MOC and the preceding version 1.0 are:
Reference Interoperable Implementations(Indicate here the links to at least two Reference Interoperable Implementations)
select top 100 * from rr.stc_spatial where 1=contains(point(10, 10), coverage) and 0=contains(point(20, 20), coverage)on http://dc.g-vo.org/tap. Implementations Validators
Comments Prior to Official RFC PeriodAs I was considering semantic validation cases, I noticed this sentence in section 2.3.2:"Warning: In this basic simple ASCII string format the values may be not sorted, and the MOC may be not well-formed."which seems to contradict section 2.2.3: " An encoded MOC must also be “well-formed”. To keep the canonical property of MOC, the redundant cells are not allowed and the hierarchical encoding principle must be respected. Thus it is not allowed to encode 4 sibling cells instead of their parent (only at level 0 for the 12 first diamonds). Using this simple constraint, there is one and only one way to describe a specific region and this makes the interoperability principle easy to implement."Maybe the former was just a legacy from MOC 1.0 where ASCII MOC was less formal, perhaps intended for hand-crafted MOCs not intended for serious use. With ASCII MOC now being formalized, can we remove that sentence and require that ASCII MOCs must be just as well-formed as their FITS counterparts? -- TomDonaldson - 2019-06-14 Comments from the IVOA Community during RFC/TCG review period: 2019-06-14 - 2019-07-29The comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name 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 WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document | ||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||
Comments from TCG member during the RFC/TCG Review Period: 2019-06-14 - 2019-07-29WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupMOC specification changes to bring String serialization to the normative part looks a good addition to this standard. The document itself is fine in general. I have two small things I'd like to point out.
Data Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working Group | ||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||
> > | The Semantics WG doesn't see anything concerning us in the proposed changes (that otherwise sound reasonable and useful to us). The spurious indent of the rule for moc in the EBNF grammar could be removed, though. -- MarkusDemleitner - 2019-07-16 | |||||||||||||||||||||||||||||||||||
Data Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsMostly OK, but some comments:
| ||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||
-- MarkTaylor - 2019-07-13
Standards and Processes CommitteeTCG Vote: 2019-06-14 - 2019-07-29If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| ||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||
<--
| ||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||
|
MOC 1.1 Proposed Recommendation: Request for Comments
SummaryLatest Draft: MOC 1.1 (Proposed Recommendation) The substantive differences between version 1.1 of MOC and the preceding version 1.0 are:
Reference Interoperable Implementations(Indicate here the links to at least two Reference Interoperable Implementations)
select top 100 * from rr.stc_spatial where 1=contains(point(10, 10), coverage) and 0=contains(point(20, 20), coverage)on http://dc.g-vo.org/tap. Implementations Validators
Comments Prior to Official RFC PeriodAs I was considering semantic validation cases, I noticed this sentence in section 2.3.2:"Warning: In this basic simple ASCII string format the values may be not sorted, and the MOC may be not well-formed."which seems to contradict section 2.2.3: " An encoded MOC must also be “well-formed”. To keep the canonical property of MOC, the redundant cells are not allowed and the hierarchical encoding principle must be respected. Thus it is not allowed to encode 4 sibling cells instead of their parent (only at level 0 for the 12 first diamonds). Using this simple constraint, there is one and only one way to describe a specific region and this makes the interoperability principle easy to implement."Maybe the former was just a legacy from MOC 1.0 where ASCII MOC was less formal, perhaps intended for hand-crafted MOCs not intended for serious use. With ASCII MOC now being formalized, can we remove that sentence and require that ASCII MOCs must be just as well-formed as their FITS counterparts? -- TomDonaldson - 2019-06-14 Comments from the IVOA Community during RFC/TCG review period: 2019-06-14 - 2019-07-29The comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name 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 WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document
Comments from TCG member during the RFC/TCG Review Period: 2019-06-14 - 2019-07-29WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupMOC specification changes to bring String serialization to the normative part looks a good addition to this standard. The document itself is fine in general. I have two small things I'd like to point out.
Data Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working GroupData Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperations | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
Mostly OK, but some comments:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Standards and Processes CommitteeTCG Vote: 2019-06-14 - 2019-07-29If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
<--
|
MOC 1.1 Proposed Recommendation: Request for Comments
SummaryLatest Draft: MOC 1.1 (Proposed Recommendation) The substantive differences between version 1.1 of MOC and the preceding version 1.0 are:
Reference Interoperable Implementations(Indicate here the links to at least two Reference Interoperable Implementations)
select top 100 * from rr.stc_spatial where 1=contains(point(10, 10), coverage) and 0=contains(point(20, 20), coverage)on http://dc.g-vo.org/tap. Implementations Validators
Comments Prior to Official RFC PeriodAs I was considering semantic validation cases, I noticed this sentence in section 2.3.2:"Warning: In this basic simple ASCII string format the values may be not sorted, and the MOC may be not well-formed."which seems to contradict section 2.2.3: " An encoded MOC must also be “well-formed”. To keep the canonical property of MOC, the redundant cells are not allowed and the hierarchical encoding principle must be respected. Thus it is not allowed to encode 4 sibling cells instead of their parent (only at level 0 for the 12 first diamonds). Using this simple constraint, there is one and only one way to describe a specific region and this makes the interoperability principle easy to implement."Maybe the former was just a legacy from MOC 1.0 where ASCII MOC was less formal, perhaps intended for hand-crafted MOCs not intended for serious use. With ASCII MOC now being formalized, can we remove that sentence and require that ASCII MOCs must be just as well-formed as their FITS counterparts? -- TomDonaldson - 2019-06-14 Comments from the IVOA Community during RFC/TCG review period: 2019-06-14 - 2019-07-29The comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name 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 WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Comments from TCG member during the RFC/TCG Review Period: 2019-06-14 - 2019-07-29WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupMOC specification changes to bring String serialization to the normative part looks a good addition to this standard. The document itself is fine in general. I have two small things I'd like to point out.
Data Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working GroupData Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote: 2019-06-14 - 2019-07-29If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
<--
|
MOC 1.1 Proposed Recommendation: Request for Comments
SummaryLatest Draft: MOC 1.1 (Proposed Recommendation) The substantive differences between version 1.1 of MOC and the preceding version 1.0 are:
Reference Interoperable Implementations(Indicate here the links to at least two Reference Interoperable Implementations)
select top 100 * from rr.stc_spatial where 1=contains(point(10, 10), coverage) and 0=contains(point(20, 20), coverage)on http://dc.g-vo.org/tap. Implementations Validators
Comments Prior to Official RFC PeriodAs I was considering semantic validation cases, I noticed this sentence in section 2.3.2:"Warning: In this basic simple ASCII string format the values may be not sorted, and the MOC may be not well-formed."which seems to contradict section 2.2.3: " An encoded MOC must also be “well-formed”. To keep the canonical property of MOC, the redundant cells are not allowed and the hierarchical encoding principle must be respected. Thus it is not allowed to encode 4 sibling cells instead of their parent (only at level 0 for the 12 first diamonds). Using this simple constraint, there is one and only one way to describe a specific region and this makes the interoperability principle easy to implement."Maybe the former was just a legacy from MOC 1.0 where ASCII MOC was less formal, perhaps intended for hand-crafted MOCs not intended for serious use. With ASCII MOC now being formalized, can we remove that sentence and require that ASCII MOCs must be just as well-formed as their FITS counterparts? -- TomDonaldson - 2019-06-14 Comments from the IVOA Community during RFC/TCG review period: 2019-06-14 - 2019-07-29The comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name 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 WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this documentComments from TCG member during the RFC/TCG Review Period: 2019-06-14 - 2019-07-29WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working GroupData Access Layer Working Group | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
MOC specification changes to bring String serialization to the normative part looks a good addition to this standard. The document itself is fine in general. I have two small things I'd like to point out.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Data Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working GroupData Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote: 2019-06-14 - 2019-07-29If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
<--
|
MOC 1.1 Proposed Recommendation: Request for Comments
SummaryLatest Draft: MOC 1.1 (Proposed Recommendation) The substantive differences between version 1.1 of MOC and the preceding version 1.0 are:
Reference Interoperable Implementations(Indicate here the links to at least two Reference Interoperable Implementations)
select top 100 * from rr.stc_spatial where 1=contains(point(10, 10), coverage) and 0=contains(point(20, 20), coverage)on http://dc.g-vo.org/tap. Implementations Validators | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | (If any, indicate here the links to Implementations Validators) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Comments Prior to Official RFC Period | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
As I was considering semantic validation cases, I noticed this sentence in section 2.3.2:
"Warning: In this basic simple ASCII string format the values may be not sorted, and the MOC may be not well-formed."which seems to contradict section 2.2.3: " An encoded MOC must also be “well-formed”. To keep the canonical property of MOC, the redundant cells are not allowed and the hierarchical encoding principle must be respected. Thus it is not allowed to encode 4 sibling cells instead of their parent (only at level 0 for the 12 first diamonds). Using this simple constraint, there is one and only one way to describe a specific region and this makes the interoperability principle easy to implement."Maybe the former was just a legacy from MOC 1.0 where ASCII MOC was less formal, perhaps intended for hand-crafted MOCs not intended for serious use. With ASCII MOC now being formalized, can we remove that sentence and require that ASCII MOCs must be just as well-formed as their FITS counterparts? -- TomDonaldson - 2019-06-14 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | Comments from the IVOA Community during RFC/TCG review period: RFC_start_date_TBD - RFC_end_date_TBD | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | Comments from the IVOA Community during RFC/TCG review period: 2019-06-14 - 2019-07-29 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The comments from the TCG members during the RFC/TCG review should be included in the next section.
In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name 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 WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | Comments from TCG member during the RFC/TCG Review Period: RFC_start_date_TBD - RFC_end_date_TBD | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | Comments from TCG member during the RFC/TCG Review Period: 2019-06-14 - 2019-07-29 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment.
IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.
TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working GroupData Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes Committee | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | TCG Vote: RFC_start_date_TBD - RFC_end_date_TBD | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | TCG Vote: 2019-06-14 - 2019-07-29 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
<--
|
MOC 1.1 Proposed Recommendation: Request for Comments
Summary | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | Latest Draft: MOC 1.1 (officially Working Draft) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | Latest Draft: MOC 1.1 (Proposed Recommendation) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The substantive differences between version 1.1 of MOC and the preceding version 1.0 are: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Reference Interoperable Implementations(Indicate here the links to at least two Reference Interoperable Implementations)
select top 100 * from rr.stc_spatial where 1=contains(point(10, 10), coverage) and 0=contains(point(20, 20), coverage)on http://dc.g-vo.org/tap. Implementations Validators(If any, indicate here the links to Implementations Validators)Comments Prior to Official RFC Period | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | Comment here prior to the official RFC period. Include your Wiki Name. Discussion can be continued on the mailing list (apps@ivoa.net). | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | Ignore Below Until RFC Period Starts | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | Comments from the IVOA Community during RFC/TCG review period: RFC_start_date_TBD - RFC_end_date_TBD | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | Comments from the IVOA Community during RFC/TCG review period: RFC_start_date_TBD - RFC_end_date_TBD | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The comments from the TCG members during the RFC/TCG review should be included in the next section.
In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name 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 WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | Comments from TCG member during the RFC/TCG Review Period: TCG_start_date_TBD - TCG_end_date_TBD | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | Comments from TCG member during the RFC/TCG Review Period: RFC_start_date_TBD - RFC_end_date_TBD | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment.
IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.
TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working GroupData Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes Committee | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | TCG Vote : Vote_start_date - Vote_end_date | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | TCG Vote: RFC_start_date_TBD - RFC_end_date_TBD | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
<--
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
MOC 1.1 Proposed Recommendation: Request for Comments
SummaryLatest Draft: MOC 1.1 (officially Working Draft) The substantive differences between version 1.1 of MOC and the preceding version 1.0 are:
Reference Interoperable Implementations(Indicate here the links to at least two Reference Interoperable Implementations)
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
To see non-trivial examples for ASCII MOCs coming out of a database, run something like
select top 100 * from rr.stc_spatial where 1=contains(point(10, 10), coverage) and 0=contains(point(20, 20), coverage)on http://dc.g-vo.org/tap. Implementations Validators(If any, indicate here the links to Implementations Validators)Comments Prior to Official RFC PeriodComment here prior to the official RFC period. Include your Wiki Name. Discussion can be continued on the mailing list (apps@ivoa.net).Ignore Below Until RFC Period StartsComments from the IVOA Community during RFC/TCG review period: RFC_start_date_TBD - RFC_end_date_TBDThe comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name 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 WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this documentComments from TCG member during the RFC/TCG Review Period: TCG_start_date_TBD - TCG_end_date_TBDWG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working GroupData Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : Vote_start_date - Vote_end_dateIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
<--
|
MOC 1.1 Proposed Recommendation: Request for Comments
SummaryLatest Draft: MOC 1.1 (officially Working Draft) The substantive differences between version 1.1 of MOC and the preceding version 1.0 are:
Reference Interoperable Implementations(Indicate here the links to at least two Reference Interoperable Implementations) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
select top 100 * from rr.stc_spatial where 1=contains(point(10, 10), coverage) and 0=contains(point(20, 20), coverage)on http://dc.g-vo.org/tap. Implementations Validators(If any, indicate here the links to Implementations Validators)Comments Prior to Official RFC PeriodComment here prior to the official RFC period. Include your Wiki Name. Discussion can be continued on the mailing list (apps@ivoa.net).Ignore Below Until RFC Period StartsComments from the IVOA Community during RFC/TCG review period: RFC_start_date_TBD - RFC_end_date_TBDThe comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name 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 WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this documentComments from TCG member during the RFC/TCG Review Period: TCG_start_date_TBD - TCG_end_date_TBDWG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working GroupData Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : Vote_start_date - Vote_end_dateIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
<--
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
MOC 1.1 Proposed Recommendation: Request for Comments
SummaryLatest Draft: MOC 1.1 (officially Working Draft) The substantive differences between version 1.1 of MOC and the preceding version 1.0 are:
Reference Interoperable Implementations(Indicate here the links to at least two Reference Interoperable Implementations) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
To see non-trivial examples for ASCII MOCs coming out of a database, run something like | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | select top 100 * from rr.stc_spatial | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | select top 100 * from rr.stc_spatial | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
where 1=contains(point(10, 10), coverage)
and 0=contains(point(20, 20), coverage)
on http://dc.g-vo.org/tap.
Implementations Validators(If any, indicate here the links to Implementations Validators)Comments Prior to Official RFC PeriodComment here prior to the official RFC period. Include your Wiki Name. Discussion can be continued on the mailing list (apps@ivoa.net).Ignore Below Until RFC Period StartsComments from the IVOA Community during RFC/TCG review period: RFC_start_date_TBD - RFC_end_date_TBDThe comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name 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 WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this documentComments from TCG member during the RFC/TCG Review Period: TCG_start_date_TBD - TCG_end_date_TBDWG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working GroupData Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : Vote_start_date - Vote_end_dateIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
<--
|
MOC 1.1 Proposed Recommendation: Request for Comments
SummaryLatest Draft: MOC 1.1 (officially Working Draft) The substantive differences between version 1.1 of MOC and the preceding version 1.0 are:
Reference Interoperable Implementations(Indicate here the links to at least two Reference Interoperable Implementations) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
select top 100 * from rr.stc_spatial where 1=contains(point(10, 10), coverage) and 0=contains(point(20, 20), coverage)on http://dc.g-vo.org/tap. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Implementations Validators(If any, indicate here the links to Implementations Validators)Comments Prior to Official RFC PeriodComment here prior to the official RFC period. Include your Wiki Name. Discussion can be continued on the mailing list (apps@ivoa.net).Ignore Below Until RFC Period StartsComments from the IVOA Community during RFC/TCG review period: RFC_start_date_TBD - RFC_end_date_TBDThe comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name 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 WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this documentComments from TCG member during the RFC/TCG Review Period: TCG_start_date_TBD - TCG_end_date_TBDWG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working GroupData Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : Vote_start_date - Vote_end_dateIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
<--
|
MOC 1.1 Proposed Recommendation: Request for Comments
SummaryLatest Draft: MOC 1.1 (officially Working Draft) The substantive differences between version 1.1 of MOC and the preceding version 1.0 are: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Reference Interoperable Implementations(Indicate here the links to at least two Reference Interoperable Implementations) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Implementations Validators(If any, indicate here the links to Implementations Validators)Comments Prior to Official RFC PeriodComment here prior to the official RFC period. Include your Wiki Name. Discussion can be continued on the mailing list (apps@ivoa.net).Ignore Below Until RFC Period StartsComments from the IVOA Community during RFC/TCG review period: RFC_start_date_TBD - RFC_end_date_TBDThe comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name 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 WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this documentComments from TCG member during the RFC/TCG Review Period: TCG_start_date_TBD - TCG_end_date_TBDWG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working GroupData Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : Vote_start_date - Vote_end_dateIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
<--
|
MOC 1.1 Proposed Recommendation: Request for Comments
SummaryLatest Draft: MOC 1.1 (officially Working Draft) The substantive differences between version 1.1 of MOC and the preceding version 1.0 are:
Reference Interoperable Implementations(Indicate here the links to at least two Reference Interoperable Implementations)Implementations Validators(If any, indicate here the links to Implementations Validators)Comments Prior to Official RFC PeriodComment here prior to the official RFC period. Include your Wiki Name. Discussion can be continued on the mailing list (apps@ivoa.net).Ignore Below Until RFC Period StartsComments from the IVOA Community during RFC/TCG review period: RFC_start_date_TBD - RFC_end_date_TBDThe comments from the TCG members during the RFC/TCG review should be included in the next section. In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name 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 WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this documentComments from TCG member during the RFC/TCG Review Period: TCG_start_date_TBD - TCG_end_date_TBDWG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice ChairApplications Working GroupData Access Layer Working GroupData Model Working GroupGrid & Web Services Working GroupRegistry Working GroupSemantics Working GroupData Curation & Preservation Interest GroupEducation Interest GroupKnowledge Discovery Interest GroupSolar System Interest GroupTheory Interest GroupTime Domain Interest GroupOperationsStandards and Processes CommitteeTCG Vote : Vote_start_date - Vote_end_dateIf you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
<--
|