STC-S in DataLink

[Tim Jenness]

On Jun 20, 2013, at 07:46 , Markus Demleitner <msdemlei at ari.uni-heidelberg.de>
 wrote:
> 
> And here's now my offer: I'd write up EBNF and accompanying prose for
> something that's "pretty much" like STC-S according to the current note,
> leaving existing usages of STC-S intact and simplifying the remaining
> rules to, e.g., allow both (1) and (2).  I'd have it ready for Hawaii,
> complete with an implementation that at least can move the stuff to
> STC-X and VOTable utypes.
> 
> Both encouragement and, erm, well, let's say discouragement is welcome
> (since this definitely would not be a standard I'd enjoy writing, I'd
> actually appreciate the latter a bit more…)

This was an interesting discussion. So are you saying you would be trying to update the STC-S definition to make it easier to parse, but backwards compatible, or that you would be creating a whole new variant? Would STC-S be deprecated? Do you have a list of all the software that deals with STC-S and what features they have implemented?

I ask because I worry about about existing STC-S parsers being broken. The AST library has pretty extensive support for STC-S (ok, not the planet rest frames) and we have software that generates STC-S definitions for emission regions in maps. We are planning to upload catalogs through CADC that specify extended emission regions in STC-S (we don't have point sources in the submm).

See for example: http://adsabs.harvard.edu/abs/2010ASPC..434..213B

-- 
Tim Jenness