MOC ASCII well-formed or not.

[Tom Donaldson]

Hi Pierre,

Thanks for the explanation.  That background makes sense to me, and I support the suggestion to give legal ASCII MOCs the same constraints as FITS MOCs by simply removing that sentence.

Thanks,
Tom


From: <apps-bounces at ivoa.net> on behalf of Pierre Fernique <Pierre.Fernique at astro.unistra.fr>
Date: Tuesday, June 18, 2019 at 10:12 AM
To: Applications WG <apps at ivoa.net>
Subject: MOC ASCII well-formed or not.


Hi Tom & apps members,

Concerning your comment on ASCII MOC on the RFC page,

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?

As an ASCII MOC is often written by hand (in a Web form for instance, or
as an Aladin script command), it was difficult to insure that it is
always well formed at this level. Is it an ASCII MOC, yes, but
potentially not well formed (ex: 3/1-210) . So the tools which have to
manipulate such ASCII MOCs must check before used. At the opposite, FITS
MOC is always generated by a code. So there is a real interest to force
it to be stored well-formed for accelerating the future reloads.

That said, you right that it is a little bit inhomogeneous, and the
ASCII MOCs will be used in other contexts that just for forms and
scripts. So we can considere that an ASCII MOC written by hand is not -
strickly speaking an ASCII MOC (not serialized in a file) - and in this
consideration -  extend the well-formed constraint to all serialized MOC
formats (FITS & ASCII) by just removing the sentence.

How does it sound ?

Cheers
Pierre



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20190619/e438b0cf/attachment.html>