SIAP and encoding of POS input parameter

[Douglas Tody]

Hi -

It appears that all the cases mentioned are (fortunately) consistent,
so we should be able to pass at least basic integer/real numbers
around consistently (i.e., a leading +- is permitted, and E is used
for the exponent).  ISO8601 is another such standard which we use
widely in contexts where it is appropriate.

I agree with Alberto that the most important bits should be stated
in every such document, although we should probably permit a reference
to another document or standard for the details, in cases where multiple
interfaces share common standards.

 	- Doug


On Wed, 21 Jan 2009, Alberto Micol wrote:

>
> 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/
>