SIAP and encoding of POS input parameter

[Alberto Micol]

Interesting Mark, very useful.

What if a SSAP returned VOtable is passed through SAMP to an application
that will use those numbers to compose a TAP ADQL query to some other 
archive?
Will all these components have to re-parse and re-translate the numbers 
to comply
to the different standards?

Alberto

>
> On 21 Jan 2009, at 20:22, Mark Taylor wrote:
>
> 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.
>
> This sort of thing should certainly be mandated explicitly in DAL and
> other standards, otherwise there is no way to guarantee interoperability.
> It's not good enough to leave it to the default assumptions of whatever
> language the protocol is implemented in.
>
> Several standards do spell this out.  VOTable says it with words, e.g.:
>
>   - Single Precision Floating Point:  ...
>     The representation of a Floating Point number in the TABLEDATA
>     serialization is made of an optional - or +, followed by the ASCII
>     representation of a positive decimal number, and followed eventually
>     by the ASCII letter "E" or "e" introducing the base-10 exponent
>     made of an optional - or + followed by 1 or 2 digits. The number
>     must be within the limits of the IEEE floating-point definition
>     (around ±3.4·1038; numbers with absolute value less than about
>     1.4·10-45 are equated to zero); the default representation of a
>     null value is an empty cell (see VALUES definitions above), and
>     the special values "+Inf", "-Inf", and "NaN" are accepted.
>
> and SAMP uses BNF:
>
>     <digit>        ::= "0" | "1" | "2" | "3" | "4" | "5" | "6"
>                      | "7" | "8" | "9"
>     <digits>       ::= <digit> | <digits> <digit>
>     <float-digits> ::= <digits> | <digits> "." | "." <digits>
>                      | <digits> "." <digits>
>     <sign>         ::= "+" | "-"
>
>     <SAMP float>   ::= [ <sign> ] <float-digits>
>                        [ "e" | "E" [ <sign> ] <digits> ]
>         A floating point value is encoded as a mantissa with an optional
>         preceding sign followed by an optional exponent part introduced
>         with the character "e" or "E". There is no guarantee about the
>         largest or smallest values which can be represented or about
>         the number of digits of precision which are significant, since
>         these will depend on the processing environment at decode time.
>
> It would make sense for these things to be consistent across all the
> IVOA standards, but different contexts have different requirements or 
> obvious implementations; for instance something which is evaluated or
> validated in the context of an XML schema should most obviously use
> the XML Schema definition, but this might impose an unnecessary burden
> in non-XML-based contexts.
>
> The main thing is that it is spelled out in each case, either explicitly
> or by reference to some other standard.
>
> Mark
>
> -- 
> Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
> m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/