MOC 2.0 WD Feedback

Fri Mar 12 17:05:53 CET 2021

Hi Mark et al.,

Le 11/03/2021 à 10:31, Mark Taylor a écrit :
> 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?

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 (/order/npix or order/range.../). 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).

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.

If there is no strong opposition and the other redactors agree, I think 
it would make sense to reintroduce this alternative. Ada ? Daniel ?

Cheers
Pierre

>
> 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20210312/2074d335/attachment-0001.html>