SIAP and encoding of POS input parameter
dtody at nrao.edu
Wed Jan 21 12:34:12 PST 2009
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.
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
> Will all these components have to re-parse and re-translate the numbers to
> to the different standards?
>> 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
>> 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 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/
More information about the dal