SIA 2.0 POS parameters

[Patrick Dowler]

curl will perform url-encoding for you if called in the right way :-)


At the highest level, the question here is whether we want to impose a 
design constraint that url-encoding of parameters is *never* required. 
That is the only way we can say anything to client writers and users 
(who script stuff with curl) other than "be safe: always encode 
parameter values".

I do not think we can impose that constraint simply because there is an 
IAU standard for naming things that uses a + sign and many astronomers 
name things like files in that style, with the + sign, and it breaks all 
over the place unless everyone is consistently following the above 
safety advice. We would break a ton of things if we started telling 
people they don't need to encode...


At the lowest level, the current design has a micro-syntax that is 
readable and users can learn it in about 5 seconds. There are numerous 
other syntaxes, e.g. the functional one, that are also readable and can 
be learned in ~5 seconds. The current stringy one has a decent tie-n 
with what users might type into a form/UI, while the functional one has 
a better tie-in with ADQL...


In the middle, using any syntax is more compact and query constraints 
are self-contained, at the expense of making the service description 
using the DALI mechanism more ad-hoc (current best idea: define values 
for and use xtype for custom params, or rely on standardID for standard 
params in standard services) because those mechanisms have limited 
expressive power. But that's a long-standing discussion which has 
evolved and I think concluded with agreements at the last two interops 
to use a simple syntax and work on improving the metadata later.

Pat



On 08/07/14 11:03 AM, Walter Landry wrote:
> Patrick Dowler <patrick.dowler at nrc-cnrc.gc.ca> wrote:
>>
>> While it is nice if param values do not have to be encoded/decoded,
>> good web software always encodes and decodes just-in-case.
>
> Curl does not encode the string you give it.
>
>> Yes, it makes it hard to type URLs and (more importantly to me) very
>> hard to read/check the encoded ones.
>>
>> I have implemented the current POS parsing and it works.
>>
>> I have implemented the functional syntax in the past (service no
>> longer operational). The parser was uglier and the error messages were
>> more opaque, but it worked. In some previous exploratory work on PQL
>> by Daniel Durand, the functional style seemed to be more generally
>> useful beyond structured values, but that was just blue-sky thinking
>> :-)
>
> I agree that it is slightly more complicated to parse.  However, the
> syntax is still simple enough that you can use a regex.  So I do not
> think that there is much of a burden for a simple service.
>
> What I really do not like is that it is yet another syntax.
>
> Cheers,
> Walter Landry
>

-- 

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)