SIAP and encoding of POS input parameter

[Doug Tody]

Hi -

Tom's mention of XML schema reminded me of what we actually said about this.
Here is what we have in the SSA spec (intended to apply to all of DAL2):

     Integer numbers are represented as defined in the specification of
     integers in XML Schema Datatypes. Real numbers are represented
     as specified for double precision numbers in XML Schema
     Datatypes. Sexagesimal formatting is not permitted, either for
     parameter input or in output metadata, other than in ISO 8601
     formatted time strings (sexagesimal format is fine for a user
     interface but inappropriate for a lower level machine interface,
     where it only complicates things).

A basic POS is thus a list of integer or real numbers delimited by
commas, with the numbers represented as defined in XML Schema Datatypes.

 	- Doug


On Wed, 21 Jan 2009, Tom McGlynn wrote:

> Hi Thomas,
>
> I agree that this should be spelled out somewhere very explicitly.
> Personally I believe that all of the examples you give should be valid.
>
> We could define a regular expression that mandates the syntax that DAL 
> services are expected to support for real numbers, e.g. something like
>
>   [+-]?(\d+(\.\d*)?|\.\d+)([eE](+-)?\d+)?
>
> might work.  [The complex bit is to allow both '10.' and '.10' but not just 
> '.']
>
> Then we'd know if we needed to support 'D/d' in the exponent, what to do with 
> spaces, and so forth.
>
> This kind of thing could be put in an IVOA note or might be worth codifying 
> in its own RFC.  I don't think this belongs in the individual DAL services 
> though.  Similar things, like what characters are valid in String's? Do we 
> have any support for Unicode in parameters?  could also be addressed.  I 
> can't recall if the VOTable standard dealt with this explicitly or inherited 
> definitions from XML.
>
> 	Tom
>
>
>
>
> Thomas Boch wrote:
>>  Hi Doug,
>>
>>  Thank you for your prompt reply.
>>
>>  Besides the '+' character, we can also question whether we allow
>>  scientific notation ( SIZE=2.5e-3 for instance). You might think I am
>>  too picky, but that is the kind of cases you might encounter when
>>  developping DAL clients or services.
>>
>>  My personal feeling is that it would make sense for the various DAL
>>  protocols to explicitely describe how the values should be encoded, ie
>>  describing what a legal number is.
>>
>>  Thomas
>>
>>  Doug Tody wrote:
>> >  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
>> > >
>> 
>
>