[SIAv2] upload

[Patrick Dowler]

We have over several interops discussed and weighed the use of STC-S vs 
something less. In the end we opted to define geometry values without 
metadata so the metadata could go where it belongs and not in the table 
cells (votable) or the ADQL query (eg POINT/CIRCLE/BOX/POLYGON/REGION 
functions). This would make handling of units, ref. systems, etc 
consistent between numeric values and geometry values. The arguments and 
subsequent comprimise have been beaten to death.

So, no: we are moving to not use STC-S in DAL parameters or return 
values and we will go on to remove it from ADQL as well.

As agreed at the last interop, we are also *not* taking the way-back 
machine to 1998 by dropping geometry values entirely :-)

Pat

On 11/03/14 11:30 AM, Markus Demleitner wrote:
> Hi Arnold,
>
> On Tue, Mar 11, 2014 at 09:56:01AM -0400, Arnold Rots wrote:
>> ...and you are claiming that all of this fiddling is simpler than just
>> using STC-S?
>> ;-)
>
> I feel bad for smartassing here, but as I've writte a lot of stuff
> around STC-S on the one hand and have written interfaces with the
> structured parameters I'm proposing here, I feel somewhat qualified
> for the one-word answer:
>
> Yes.
>
> And even dare to add: Both in implementation and conceptually, by a
> very noticeable factor.
>
> STC-S is good for quite a few things -- basically, every time you
> want to declare complex *metadata*, but exactly that makes it fairly
> unsuitable for serializing geometry values generated from database
> columns or for query parameters.
>
> Cheers,
>
>         Markus
>

-- 

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

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