SIAP and encoding of POS input parameter

[Jesus Salgado]

Dear all,

I fully support the creation of a (hopefully) small document/standard to
define the "DAL Query Language". This was commented in the past and it
would be quite useful for client and server developers.

This definition of valid values, ranges, lists, qualifiers, etc in DAL
syntax is more or less spread in all the DAL protocols and it is always
better to have a reference to something more complete than a summary
repetition in all the specs. 

Regards,
Jesus

On Wed, 2009-01-21 at 13:34 -0700, Douglas Tody wrote:
> 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/
> >
-- 
Jesus J. SALGADO                       Jesus.Salgado at sciops.esa.int

ESAC Science Archive Team
European Space Astronomy Centre (ESAC)
European Space Agency (ESA)

European Space Agency/European Space Astronomy Centre
P.O. Box 78
28691 Villanueva de la Canada                 Tel: +34 91 813 12 71
Madrid - SPAIN                                Fax: +34 91 813 13 08
-------------------------------------------------------------------


================================================================================================
This message and any attachments are intended for the use of the addressee or addressees only. The
unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content
is prohibited. If you received this message in error, please delete it from your system and notify
the sender. E-mails can be altered and their integrity cannot be guaranteed. ESA shall not be liable
for any e-mail if modified.
=================================================================================================