MOC 2.0 WD Feedback

[Mark Taylor]

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 https://www.ivoa.net/documents/MOC/20201112/index.html

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?

Thanks

Mark

On Thu, 11 Mar 2021, ada nebot wrote:

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

--
Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
m.b.taylor at bristol.ac.uk          http://www.star.bristol.ac.uk/~mbt/