SIAP and encoding of POS input parameter

[Tom McGlynn]

Hi Thomas,

I agree that this should be spelled out somewhere very explicitly.
Personally I believe that all of the examples you give should be valid.

We could define a regular expression that mandates the syntax that DAL 
services are expected to support for real numbers, e.g. something like

    [+-]?(\d+(\.\d*)?|\.\d+)([eE](+-)?\d+)?

might work.  [The complex bit is to allow both '10.' and '.10' but not 
just '.']

Then we'd know if we needed to support 'D/d' in the exponent, what to do 
with spaces, and so forth.

This kind of thing could be put in an IVOA note or might be worth 
codifying in its own RFC.  I don't think this belongs in the individual 
DAL services though.  Similar things, like what characters are valid in 
String's? Do we have any support for Unicode in parameters?  could also 
be addressed.  I can't recall if the VOTable standard dealt with this 
explicitly or inherited definitions from XML.

	Tom




Thomas Boch wrote:
> Hi Doug,
> 
> Thank you for your prompt reply.
> 
> Besides the '+' character, we can also question whether we allow
> scientific notation ( SIZE=2.5e-3 for instance). You might think I am
> too picky, but that is the kind of cases you might encounter when
> developping DAL clients or services.
> 
> My personal feeling is that it would make sense for the various DAL
> protocols to explicitely describe how the values should be encoded, ie
> describing what a legal number is.
> 
> Thomas
> 
> Doug Tody wrote:
>> Hi Thomas -
>>
>> So far as I can recall this is not explicitly addressed (note POS
>> issues apply to SSA as well so this is not just SIAP).  Technically
>> what we have here are two numbers separated by a comma, and this is
>> how a simple POS is defined.  So in practical terms whether or not a
>> leading "+" is accepted will depend upon the language used for the
>> implementation, how it lexically defines a number, and whether "+"
>> is permitted as the first character in a number.  Some languages will
>> permit "+" as the first character of a number, but I don't think this
>> is always the case.
>>
>> If one is writing a client app the safest thing to do is omit the
>> leading "+".  If one is writing a service the safest thing to do it
>> accept it.  Typical codes however will use the parsing facilities
>> provided by the host language, which may or may not permit the leading
>> "+".  This is probably the cause of the inconsistent behavior you
>> are seeing (and is a common problem in other contexts as well).
>>
>> For maximum generality we could consider requiring than an explicit
>> leading plus sign be permitted, although I suspect that this is a
>> subtle enough point that many service implementations might miss.
>>
>>         - Doug
>>
>> On Wed, 21 Jan 2009, Thomas Boch wrote:
>>
>>> Dear DALers,
>>>
>>> While playing with some SIAP services the other day, I found out that
>>> some of them did not like the declination part of the POS input
>>> parameter to be started by a '+' (properly escaped as %2B).
>>> Example :
>>> http://mysiap.org/query?POS=83.6,22.0144&SIZE=0.2      is understood
>>> whereas:
>>> http://mysiap.org/query?POS=83.6,%2B22.0144&SIZE=0.2   is processed as
>>> an error.
>>>
>>> After checking in the SIAP document, I found nothing explicit about how
>>> the value of the POS parameter should be encoded.
>>>
>>> Has anyone any comment on that ?
>>> Cheers,
>>>
>>> Thomas
>>>
>