New version of the SIA V2.0 PR

[Walter Landry]

For RANGE, I did not get any feedback beyond what is on the wiki.  For
syntax, there was a fair amount of interest in my new implementation
but no one was willing to commit to a new order of things.

Cheers,
Walter Landry

Bruce Berriman <gbb at ipac.caltech.edu> wrote:
> Thanks - now, did you receive any feedback after your talk on the two issues below?
> 
> Cheers
> 
> bruce
> 
> 
> On Nov 3, 2014, at 10:38 AM, Walter Landry <wlandry at caltech.edu> wrote:
> 
>> Hello Everyone,
>> 
>> I have discussed my issues with SIA v2 in other forums, but I was told
>> I should express them here for the TCG.
>> 
>> As background, I tried to implement an SIA v2 service for a virtual
>> image service for the Planck satellite.  This is a use case that SIA
>> v1.0 covered well with its support for Image Mosaicing Service, but
>> now seems to have been split off into AccessData.  I gave a talk about
>> my experience at the Banff Interop [1], so this email is a
>> distillation of the problems I found.
>> 
>> 1) RANGE
>> 
>>   Section 2.1.1 includes a RANGE shape.  A RANGE is not a square on
>>   the sky, but users could easily think that it is.  This makes it
>>   error-prone.
>> 
>>   Also, a RANGE shape is significantly different from the other two
>>   types, so it could be a non-trivial amount of work to implement.
>>   In my particular case, it was enough work such that I did not
>>   implement it, though I did implement CIRCLE and POLYGON.  This is
>>   in contrast to something like a BOX shape, which only requires
>>   transforming the BOX into an equivalent POLYGON.
>> 
>>   Finally, the only use case that I have heard for RANGE is for
>>   tiling the sky.  However, tiling the sky is fairly easy with a
>>   POLYGON.
>> 
>> 2) Syntax
>> 
>>   SIA v2 invents yet another syntax.  This creates an unnecessary
>>   burden on both implementors and users.  The syntax that was chosen
>>   is also error-prone.  We should reuse an existing syntax.  In my
>>   presentation [1], I presented my work on using Javascript syntax.
>>   It preserves the simplicity of key-value parameters while scaling
>>   to extremely complex inputs.  But whatever is decided, please do
>>   not invent a new syntax.
>> 
>> Cheers,
>> Walter Landry
>> 
>> 
>> [1] http://wiki.ivoa.net/internal/IVOA/InterOpOct2014DAL/Wlandry_DAL_I.pdf
>