Call for MOC 1.1 validators

[Tom Donaldson]

Hi Apps,

Thank you very much, Markus, for creating this validator!  I’ll add a reference to it on the RFC page and get the RFC period started.

I was able to try it out on a variety of cases, and didn’t encounter any problems.  That exercise did get me to think about a few things, some of which may be worth more discussion:

This Validator:

Thanks for introducing me to pyparsing!  Very nice.

This validator so far only checks syntax.  It would be nice to have deeper checks, but maybe that should be the domain of some of the other implementations that need to understand the content anyway.

As an exercise, I added a bit of code to this validator to check that pixel values are not too big for their order, and that the first value in a pixel range is less than the second value.  I'll send that along separately so you can take a look and see if you'd like to use it.


The Document:

As I was considering semantic validation cases, I noticed this sentence in section 2.3.2:

"Warning: In this basic simple ASCII string format the values may be not sorted, and the MOC may be not well-formed."

which seems to contradict section 2.2.3:

" An encoded MOC must also be “well-formed”. To keep the canonical property of MOC, the redundant cells are not allowed and the hierarchical encoding principle must be respected. Thus it is not allowed to encode 4 sibling cells instead of their parent (only at level 0 for the 12 first diamonds). Using this simple constraint, there is one and only one way to describe a specific region and this makes the interoperability principle easy to implement."

Maybe the former was just a legacy from MOC 1.0 where ASCII MOC was less formal, perhaps intended for hand-crafted MOCs not intended for serious use.  With ASCII MOC now being formalized, can we remove that sentence and require that ASCII MOCs must be just as well-formed as their FITS counterparts?


Implementations as part of the process:

I have been slow a couple times now to promote the need for interoperable implementations and validators, and I'm sorry for slowing down the process in that way.  That said, I think these implementations are important, but I don't think we have very clear guidelines as to what needs to be developed or demonstrated.  

For example, we have several implementations for MOC 1.1, but I don't know if anyone has tried having them interoperate.  If so, it would be great to put notes about that on the RFC page.  If not, it would be great if some experiments can be tried now during the RFC period.  I noticed that the Aladin ASCII MOC writer starts the MOC with a comment line indicating the order of the MOC.  That comment is flagged as invalid by this new validator, but it may be a very good idea to enhance the grammar to allow one (or more?) comment lines.  Running such experiments may bring up useful discussions about the standard.


Regards,
Tom

 

On 6/12/19, 5:46 AM, "apps-bounces at ivoa.net on behalf of Markus Demleitner" <apps-bounces at ivoa.net on behalf of msdemlei at ari.uni-heidelberg.de> wrote:

    Hi Apps,
    
    On Thu, May 30, 2019 at 06:10:00PM +0000, Tom Donaldson wrote:
    > The MOC 1.1 document is quite stable and ready for its official RFC
    > period.  However, the RFC page does not list any validators, and
    > that is also a prerequisite for entering RFC.  I suspect that one
    > or more of the listed implementations can act as validators, but I
    > do not know that for sure.  The one I tried did not give any
    > feedback for a corrupt ASCII MOC.
    > 
    > So if your implementation can act as a validator, please add it to
    > the validator section of the RFC page
    > (https://wiki.ivoa.net/twiki/bin/view/IVOA/MOC11RFC#Implementations_Validators),
    > along with sufficient text to explain how to use it in that
    > context.
    > 
    > I will open the official RFC period as soon as we have a validator.
    
    Since I have a major interest in getting ASCII MOCs out of the door
    (it's a prerequisite for VODataService 1.2), I went ahead and just
    wrote a validator.  I've put it onto volute (and even though the
    standard itself is non version-controllable, it might be useful to
    just put it next to it):
    
    https://volute.g-vo.org/svn/trunk/projects/apps/MOC/
    
    The validator only has a very basic command line interface: It will
    validate its standard input, unless it is called with "test" as a
    first argument, in which case the built-in tests are run.
    
    Comments are welcome (and yes, 0/1,2 4
    5,
    6,,,, 
    
     12 *is* a valid ASCII MOC; I'm not enthusiastic about that, too, but
    breaking existing software is uncool, so I guess we'll have to live
    with it).
    
            -- Markus