SIAP and encoding of POS input parameter

[Doug Tody]

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
>