STC-S in DataLink

[Patrick Dowler]

We should not forget that there is *no* STC-S recommendation, only a 
note and a non-normative section in the TAP_1.0 recommendation. So, the 
scope of an STC-S standard is still to be decided and since this is 
being done now to support some current use cases that scope could be 
quite highly constrained. For example, we could decide to constrain it 
enough that we do not feel bad about making most/all of it mandatory.

As for Markus' soliloquy, I do agree that we have in the past lied when 
we represent things as being simpler than they really are. But the lie 
is that the community has tried for too long to avoid accepting and 
using data types beyond primitive integers and floats and strings. At 
CADC we have been treating shapes (circles, polygons, etc) and intervals 
a real datatypes** for a long time now and once you do that all the 
confusion goes away -- and astronomers are fine with this (we consult 
our users while developing these features)!! I do not agree at all with 
the idea of trying to do everything with primitive datatypes and hordes 
of parameters.

I just got Arnold's latest draft and will be tidying it up as a WD and 
posting it asap. Once that is done, we can discuss what the scope of 1.0 
should be, but it really has to support the current science use cases 
(cubes and time series) and the ones from ObsTAP.

my 2c,

Pat

** not advocating that we open VOTable up again and add data types

On 06/20/2013 09:08 AM, Tim Jenness wrote:
>
> 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
>

-- 

Patrick Dowler
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9A 2L9

250-363-0044 (office) 250-363-0045 (fax)