<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<p>Hi Mark et al.,</p>
<div class="moz-cite-prefix">Le 11/03/2021 à 10:31, Mark Taylor a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:alpine.DEB.2.21.2103110929570.3429@IT076926">
<pre class="moz-quote-pre" wrap="">Ada, Francois, et al.,
I'm not necessarily against this, but in order to avoid hitting a
problem that we might have run into before: does anybody know why the
STMOC ASCII serialization was removed from the document in the first
place? It was present in an internal draft I have dated 2020-09-14,
but not at <a class="moz-txt-link-freetext" href="https://www.ivoa.net/documents/MOC/20201112/index.html">https://www.ivoa.net/documents/MOC/20201112/index.html</a>
It's possible that I was party to the conversation that resulted in
that change, but if so I don't remember. Can the authors explain
why STMOC ASCII got removed?</pre>
</blockquote>
<p>The removal of ASCII serialization for TMOCs and STMOCs in WD 2.0
had been motivated when the authors were considering the complete
removal of the temporal MOC hierarchy due to the fact that the
syntax was based on this notion of hierarchy (<i>order/npix or
order/range...</i>). As we finally decided to keep a hierarchy
(factor 2 for time and 4 for space), technically it could be
possible to reintegrate this ASCII serialization in the document
by just adjusting a little bit the text to take into account the
61 orders of time compared to the 29 of space).</p>
<p>I would be in favor of reintroducing. My current point of view is
also motivating by the fact that I'm updating Aladin Desktop to
follow the latest WD, and I admit that the removal of ASCII
serialization is a concern for me, especially in the script
commands (draw MOC ....) that requires an ASCII expression and
also to keep a global consistency for the MOCs serializations.
Also, I keep in mind the remarks of Gregory Dubois, just after my
IVOA presentation which let think me that an ASCII serialization
will be really required anymore. François Bonnarel's last mail is
also in the same direction.</p>
<p>If there is no strong opposition and the other redactors agree, I
think it would make sense to reintroduce this alternative. Ada ?
Daniel ?<br>
</p>
<p>Cheers<br>
Pierre<br>
</p>
<blockquote type="cite"
cite="mid:alpine.DEB.2.21.2103110929570.3429@IT076926">
<pre class="moz-quote-pre" wrap="">
Thanks
Mark
On Thu, 11 Mar 2021, ada nebot wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Dear Tom, Francois, and Apps,
Tom, thanks for all your comments, I will take your editorial suggestions into account.
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.
Best,
Ada
--
Astronome Adjointe
CDS, Observatoire Astronomique de Strasbourg (ObAS)
UMR 7550 Université de Strasbourg
11, rue de l'Université, F-67000 Strasbourg
+33 (0) 3 68 85 24 20
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On 10 Mar 2021, at 16:54, BONNAREL FRANCOIS <a class="moz-txt-link-rfc2396E" href="mailto:francois.bonnarel@astro.unistra.fr"><francois.bonnarel@astro.unistra.fr></a> wrote:
Dear apps, dear MOC2.0 authors
I went to this spec with my DAL point of view.
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
There is no reason that this should be restricted to space
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.
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.
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 class="moz-txt-link-freetext" href="https://ivoa.net/documents/stmoc/index.html">https://ivoa.net/documents/stmoc/index.html</a>)
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.
Cheers
François
Le 09/03/2021 à 00:42, Tom Donaldson a écrit :
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Dear Pierre, et al.,
I spent a little time reviewing the MOC 2.0 working draft (<a class="moz-txt-link-freetext" href="https://www.ivoa.net/documents/MOC/20201112/WD-MOC-2.0-20201112.pdf">https://www.ivoa.net/documents/MOC/20201112/WD-MOC-2.0-20201112.pdf</a>)
and have some feedback.
First, thank you to all the authors. I found the document well written, clearly explaining both the motivation
and required details. This functionality seems very worthwhile, and the technique well-studied and effective.
I don't have any major concerns with the content.
I could imagine some discussion about generalizing the technique further to incorporate other dimensions
such as spectral coverage. However, I note that the space and time representations are customized based on
the specific characteristics of those values, so other dimensions may need other customizations. Without
studying the use cases and values for at least one other dimension at the same level of detail as
space and time, generalizing the customizations seems premature.
I do have a few editorial suggestions:
Table of Contents
- starts with a "Todo list" referring to page 4, but there is no Todo list on that or other pages.
- does not include the Acknowledgements or Conformance-related definitions from page 5
Introduction
- Should the reference to be to MOC 1.1 instead of MOC 1.0?
Section 2.3, p14
- in "more than 73000 years at 1μ resolution", "1μ" should be "1μs".
Section 3.3
- comma unnecessary after "(coded according to the TMOC convention)". Possible alternate wording to make it a little smoother:
"by associating each time period (coded according to the TMOC convention) with its spatial region
(coded according to the SMOC convention)."
Section 4.2
- "about 1000 seconds (see Table 1)" should instead refer to Table 2 for the time resolutions.
Section 4.2.1
- awkward phrasing in, "The numbering scheme used in TMOC for specifying the time cell indices must reuse a similar hierarchical
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
mapping in addition of a progression of a factor of 2 instead of 4."
Suggest maybe:
"The numbering scheme used in TMOC for specifying the time cell indices must reuse a similar hierarchical principle as for the
SMOC with the difference that the time line has only one dimension, so the hierarchical progression uses a factor of 2 instead of 4,
and there is no need to use a HEALPix mapping."
Section 4.3.1
- in Backward compatibility, "existing library" should probably be "existing libraries".
Section 4.3.2
- 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:
moc ::= ordpix (sep+ ordpix)* [sep+ order]
ordpix ::= order sep* pixs
order ::= int ’/’
pixs ::= pix (sep+ pix)*
pix ::= int? | (int ’-’ int)
sep ::= [ \n\r]
int ::= [0-9]+
Section 5.1
- This sentence equates forcing the 64th bit to 1 with negating the integer:
"To distinguish time and space indices, the time indices must have the 64th bits forced to 1 - i. e. represented
as a negative integer."
Should we clarify that the time indices must be the twos complement negative of the actual value? This would prevent
any possible confusion between that and just masking that last bit to 1 without changing the other bits. I believe the
FITS standard uses twos complement for signed ints, but it can't hurt to be explicit.
References
- I'm not sure whether it's important for references to include URLs, or what the best links are (DOIs, etc.), but some
reference have a URL and some don't, so maybe some more consistency could be achieved?
- 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.
Best regards,
Tom
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
--
Mark Taylor Astronomical Programmer Physics, Bristol University, UK
<a class="moz-txt-link-abbreviated" href="mailto:m.b.taylor@bristol.ac.uk">m.b.taylor@bristol.ac.uk</a> <a class="moz-txt-link-freetext" href="http://www.star.bristol.ac.uk/~mbt/">http://www.star.bristol.ac.uk/~mbt/</a></pre>
</blockquote>
</body>
</html>