<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Dear Tom, Francois, and Apps,<div class=""><br class=""></div><div class="">Tom, thanks for all your comments, I will take your editorial suggestions into account.</div><div class=""><br class=""></div><div class="">Francois, concerning the ascii serialisation, thanks for pointing that out! I totally agree with you that we should bring back the ascii serialisation to the document. </div><div class=""><br class=""></div><div class="">Best, </div><div class="">Ada</div><div class=""><br class=""><div class="">
<div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">--<br class="">Astronome Adjointe<br class="">CDS, Observatoire Astronomique de Strasbourg (ObAS)<br class="">UMR 7550 Université de Strasbourg <br class="">11, rue de l'Université, F-67000 Strasbourg<br class="">+33 (0) 3 68 85 24 20</div></div></div></div></div>
</div>
<div><br class=""><blockquote type="cite" class=""><div class="">On 10 Mar 2021, at 16:54, BONNAREL FRANCOIS <<a href="mailto:francois.bonnarel@astro.unistra.fr" class="">francois.bonnarel@astro.unistra.fr</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Dear apps, dear MOC2.0 authors<br class=""><br class="">I went to this spec with my DAL point of view.<br class=""><br class="">It's now a couple of monthes (years ?) that the IVOA community point out that it would be good that DAL parameter-based protocols could use MOC as input parameters<br class=""><br class="">There is no reason that this should be restricted to space<br class=""><br class="">One obvious use case is when you get a MOC for some survey, catalog , or whatever from a previous operation in the VO and want to query a parameter-based service (Simple access service or SODA) constraining the service response using this MOC.<br class=""><br class="">Although we could imagine using the binary coding described at page 18/19 as a MOC parameter value, it would be obviously more user friendly to allow ASCII serialization there.<br class=""><br class="">By preparing a github PR for this feature in SODA I realized that Time ascii serialization doesn't exist any more in the current version of the spec. But it was the case in the preliminary note (<a href="https://ivoa.net/documents/stmoc/index.html" class="">https://ivoa.net/documents/stmoc/index.html</a>)<br class=""><br class="">I don't know the very technical reasons for this change but I think it would be useful to provide back an ASCII TMOC serialization at least to serve the extension of MOC usage to DAL protocols.<br class=""><br class="">Cheers<br class=""><br class="">François<br class=""><br class=""><br class=""><br class=""><br class="">Le 09/03/2021 à 00:42, Tom Donaldson a écrit :<br class=""><blockquote type="cite" class="">Dear Pierre, et al.,<br class=""><br class="">I spent a little time reviewing the MOC 2.0 working draft (<a href="https://www.ivoa.net/documents/MOC/20201112/WD-MOC-2.0-20201112.pdf" class="">https://www.ivoa.net/documents/MOC/20201112/WD-MOC-2.0-20201112.pdf</a>)<br class="">and have some feedback.<br class=""><br class="">First, thank you to all the authors. I found the document well written, clearly explaining both the motivation<br class="">and required details. This functionality seems very worthwhile, and the technique well-studied and effective.<br class="">I don't have any major concerns with the content.<br class=""><br class="">I could imagine some discussion about generalizing the technique further to incorporate other dimensions<br class="">such as spectral coverage. However, I note that the space and time representations are customized based on<br class="">the specific characteristics of those values, so other dimensions may need other customizations. Without<br class="">studying the use cases and values for at least one other dimension at the same level of detail as<br class="">space and time, generalizing the customizations seems premature.<br class=""><br class=""><br class="">I do have a few editorial suggestions:<br class=""><br class="">Table of Contents<br class="">- starts with a "Todo list" referring to page 4, but there is no Todo list on that or other pages.<br class="">- does not include the Acknowledgements or Conformance-related definitions from page 5<br class=""><br class="">Introduction<br class="">- Should the reference to be to MOC 1.1 instead of MOC 1.0?<br class=""><br class="">Section 2.3, p14<br class="">- in "more than 73000 years at 1μ resolution", "1μ" should be "1μs".<br class=""><br class="">Section 3.3<br class="">- comma unnecessary after "(coded according to the TMOC convention)". Possible alternate wording to make it a little smoother:<br class=""> "by associating each time period (coded according to the TMOC convention) with its spatial region<br class=""> (coded according to the SMOC convention)."<br class=""><br class="">Section 4.2<br class="">- "about 1000 seconds (see Table 1)" should instead refer to Table 2 for the time resolutions.<br class=""><br class="">Section 4.2.1<br class="">- awkward phrasing in, "The numbering scheme used in TMOC for specifying the time cell indices must reuse a similar hierarchical<br class=""> principle as for the SMOC with the difference that the time line has only one dimension, and there is no need to use an HEALPix<br class=""> mapping in addition of a progression of a factor of 2 instead of 4."<br class=""> Suggest maybe:<br class=""> "The numbering scheme used in TMOC for specifying the time cell indices must reuse a similar hierarchical principle as for the<br class=""> SMOC with the difference that the time line has only one dimension, so the hierarchical progression uses a factor of 2 instead of 4,<br class=""> and there is no need to use a HEALPix mapping."<br class=""><br class="">Section 4.3.1<br class="">- in Backward compatibility, "existing library" should probably be "existing libraries".<br class=""><br class="">Section 4.3.2<br class="">- The EBNF does not seem to allow the final index-free order (the example ends with "8/" to indicate an order of 8.) Maybe update to:<br class=""> moc ::= ordpix (sep+ ordpix)* [sep+ order]<br class=""> ordpix ::= order sep* pixs<br class=""> order ::= int ’/’<br class=""> pixs ::= pix (sep+ pix)*<br class=""> pix ::= int? | (int ’-’ int)<br class=""> sep ::= [ \n\r]<br class=""> int ::= [0-9]+<br class=""><br class="">Section 5.1<br class="">- This sentence equates forcing the 64th bit to 1 with negating the integer:<br class=""> "To distinguish time and space indices, the time indices must have the 64th bits forced to 1 - i. e. represented<br class=""> as a negative integer."<br class=""> Should we clarify that the time indices must be the twos complement negative of the actual value? This would prevent<br class=""> any possible confusion between that and just masking that last bit to 1 without changing the other bits. I believe the<br class=""> FITS standard uses twos complement for signed ints, but it can't hurt to be explicit.<br class=""><br class="">References<br class="">- I'm not sure whether it's important for references to include URLs, or what the best links are (DOIs, etc.), but some<br class=""> reference have a URL and some don't, so maybe some more consistency could be achieved?<br class="">- The MOC 1.0 reference describes it as Working Draft (it is REC) and links to the most recent version (1.1) instead of 1.0.<br class=""><br class=""><br class="">Best regards,<br class="">Tom<br class=""><br class=""><br class=""></blockquote><br class=""></div></div></blockquote></div><br class=""></div></body></html>