REC for ASCII MOCs

[Gregory MANTELET]

Dear Markus and Apps folks,

That reminds me a lot a talk I gave at the Interop in Shanghai about MOC 
and TAP - 
http://wiki.ivoa.net/internal/IVOA/InterOpMay2017-DAL/mantelet_tap-moc.pdf.

We had the same issue: having a string/ASCII serialisation of a MOC. The 
idea was to write something like:

	WHERE  1= CONTAINS(POINT(’’, ra, dec),*REGION(’MOC 2/12-20 5/60’)*)

or

	WHERE  1= CONTAINS(POINT(’’, ra, dec),*MOC(’2/12-20 5/60’)*)


For that, a standard ASCII syntax for MOC is needed. At the end of my 
talk, in the Appendices, I proposed a syntax as a proposal for a 
standard ASCII serialisation. The only difference with the one proposed 
in the section 3.1.2 of the MOC-REC document 
(http://www.ivoa.net/documents/MOC/20140602/REC-MOC-1.0-20140602.pdf), 
is the prefix "MOC". In such case, it would allow to write in ADQL 
something like the first example above (with REGION).

Anyway, in my talk, I proposed a specification for this syntax 
(especially some rules about what is allowed or not). I also gave a PEG 
grammar for this small syntax.

/Note://I just noticed a small error in the PEG grammar in these slides. 
So I attach to this email a corrected syntax. You can test this latter 
online with PegJS (//https://pegjs.org/online//) ; just copy-paste the 
grammar on the left part and then test some expressions on the right part./

Grégory



On 24/10/2018 10:38, Markus Demleitner wrote:
> Dear Apps folks,
>
> In the context of adding information on the STC coverage of resources
> (that's VODataService 1.2), we in Registry need an ASCII
> serialisation of MOCs, because the things should come embedded in
> Registry records (see the Registry-STC roadmap at
> http://ivoa.net/documents/Notes/Regstc/index.html for our rationale).
>
> Now, we like a lot the proposed syntax in 3.1.2 of the current MOC
> REC -- it's reasonably compact and readable.  But it's not a
> standard, just a suggested syntax.
>
> Since we'd like to use in in a REC, the ASCII MOC needs to be
> specified in a REC, too.  So -- how do you feel about a small update
> to MOC that takes 3.1.2 and promotes it to a normative section 2.3.3?
>
> An alternative would be to take ASCII MOCs to DALI.  In the end, DALI
> will probably have to say something about MOCs anyway, as we'll need
> an xtype=MOC if we want to (interoperably) exchange MOCs in VOTable
> columns (which I want pretty much).  If we touch DALI, it might be a
> little less work if DALI described the format itself (we'd touch only
> one standard, not two of them).
>
> Opinions?
>
>           -- Markus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20181024/e7b3e3d3/attachment.html>
-------------- next part --------------
/* THE ASCII SERIALIZATION OF A MOC
* MUST start with "MOC" (case insensitive)
* and be followed by one or more MOC_ITEMs,
* all separated by at least one space. */
MOC_ASCII = "MOC"i __ MOC_ITEM ( __ MOC_ITEM)*

/* A MOC-ITEM
* MUST start with an Healpix order, a '/'
* and zero or more Healpix indices.
*
* Theoretically, ONLY one MOC-ITEM may be composed of
* ONLY an Healpix order. This item would then represent
* the maximum order of the MOC, even if no Healpix index
* of this order is part of the MOC. */
MOC_ITEM = HPX_ORDER '/' HPX_INDICES?

/* AN HEALPIX-ORDER
* MUST be an integer between 0 and 29 (included). */
HPX_ORDER = ([12][0-9] / [0-9])

/* HEALPIX-INDICES
* CAN be:
* - a single HEALPIX-INDEX (e.g. '2398'),
* - a range (e.g. '1-9')
* - or a list of single indices and/or ranges
* (e.g. '1,3,6-98,101'). */
HPX_INDICES = HPX_INDEX (('-'/',') HPX_INDEX)*

/* AN HEALPIX-INDEX
* MUST be a long integer number (e.g. '2398').
*
* If different from the digit zero, the number
* should NOT start with zero
* (e.g. the number '012' should not be considered
* as an Healpix index). */
HPX_INDEX = ('0' / [1-9][0-9]+)

/* Mandatory spaces (at least one) */
__ = ' '+