MOC 2.0 WD Feedback

[BONNAREL FRANCOIS]

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
>
>