MOC 2.0 WD Feedback

[ada nebot]

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

> On 10 Mar 2021, at 16:54, BONNAREL FRANCOIS <francois.bonnarel at astro.unistra.fr> 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 (https://ivoa.net/documents/stmoc/index.html)
> 
> 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 :
>> Dear Pierre, et al.,
>> 
>> I spent a little time reviewing the MOC 2.0 working draft (https://www.ivoa.net/documents/MOC/20201112/WD-MOC-2.0-20201112.pdf)
>> 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
>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20210311/05fb6f9d/attachment-0001.html>