SSA-1.1

[Petr Skoda]

Hi all ,

I am glad, that the SSA1.1 is getting to the final phase.
However, as I already pointed out in Nara during discussion, there are 
still some ambiguities which a proper standard should not have. And it is 
in a most critical astronomical information - the time.

Maybe most of you did not notice the problem with stating the query 
parameter for TIME (and MTIME) but the problem is evident if you want to 
use some standard database functions to handle the time in ISO8601.

The ISO8601  is mentioned several times in SSA  (4.1.1, 4.1.1.4 and 
4.1.2.17, 4.2.5.4, 8.7.2) but I am sure (and was assured by Doug) that the 
expected format is not everything according to whole ISO standard but the 
very narrow subset.

Namely the date value should resemble the pattern YYYY-MM-DDTHH:MM:SS.S 
with the "T" between - although some explanations of ISO accept the space 
as well (and there is some confusion about the only one or two strings in 
such a case).

Another example - sure we do not want days in week or number of weeks or 
other exotic features of ISO8601 (like week date with W or ordinal dates 
YYYY-DDD)

The example in mandatory TIME parameter in 4.1.1 is also misleading as
it is not sure if the 1999 means all year 1999 or beginning of 1999 - i.e. 
whether the such a query should return everything observed between 
21.5.1998 and the end od 1998 or the end of 1999 !
(it is clear that the ordinary user will be confused as well and to be 
sure he will use both timestamps with full date representation )

Such a issues are discussed at 
http://www.cs.tut.fi/~jkorpela/iso8601.html


And I am still not sure if the TIME (or MTIME) can be expressed as
19980521 without dashes

And the last question concerns the timezones - ISO states that without Z 
the time is considered local not UTC while 4.1.1. declares the parameter 
TIME in units "ISO 8601 UTC"  The 4.1.1.4 makes it even more confusing 
stating that "if the time system used is not specified, the UTC is 
asumed". But I do not know what is the time system specification - perhaps 
the time zone ?

So in fact, what is required in SSA for time representation (see above) is 
something called TIMESTAMP and following rules in RFC3339   sec 5.6

http://tools.ietf.org/html/rfc3339


So I suggest to change the chapter 4.1.1.4 TIME to explicitly explain the 
expected form of TIME string (e.g. by refering to RFC 3339 sec 5.6 )
and adding the comment on implicit Z (UTC) if the timezone is not given.
and mandatory T (despite the comment in RFC

"NOTE: ISO 8601 defines date and time separated by "T".
       Applications using this syntax may choose, for the sake of
       readability, to specify a full-date and full-time separated by
       (say) a space character."

and give the explanation how to understand the example 1998-05-21/1999 in 
table of mandatory parameters.

Would someone try to formulate the exact rules for TIME ?
I would like to but I am not sure what was realy meant during the 
preparation of early preSSA nad we do not have any reference service to 
try it on....

or maybe we could simply refer to 4.4.2.1.1.1 par. 1. in STC
http://www.ivoa.net/Documents/REC/DM/STC-20071030.html
Where the subset of the ISO-8601 format is defined ....




  ---------------------------------
more changes to SSA (sure not breaking the current functionality of real 
services) suggested:

the Appendix A talks about hypothetical TSAP server modelserver.com but 
gives example of some real services both FORMAT=METADATA and queryData - 
however the real query (to svo.laeff.inta.es) is stated only for queryData
It is really convenient to direcly use the link in document to check 
directly the whole result (shortened in document).

I am not sure what is a query with  FORMAT=METADATA generating the output 
in the appendix A - it seems to be different from real answer of query

http://svo.laeff.inta.es/projects/svo/theory/db2vo/html/tsap.php?REQUEST=queryData&model=kurucz&format=metadata

(with confusing model=kurucz)

It is propably faked response, but I suggest for future  considerations 
the real query with real response.

But where it is really important to see example that may be played with is 
the Appendix B and C. I hope it comes from still working service (as 
stated at the begining of B) so it would be extremely interesting for 
implementors to know (and have links to ) the particular queries.

Unfortunately I do not know them -  Doug, can you add them ?

----------------------------------

There seem to be problems with references (I did not check all of them, 
but I am sure some should be upgraded to newer versions of documents - 
including the revised SDM ;-)) BUT the reference to RSM (Hanish 2005)  - 
which is important for understanding the names for BAND in 4.1.1.3 and in 
Appendix D - line for DataID.Bandpass - does not exist anymore.

So the citations should point (probably) to the RSM 1.12 (Hanish 2007)
at
http://www.ivoa.net/Documents/latest/RM.html

but I think the relevance of  other citation should be checked as well.


I still consider the changes suggested above to be minor (in fact more or 
less explanations or clarifications) and feel the need of their inclusion 
in the SSA1.1

Regards,

Petr


*************************************************************************
*  Petr Skoda                         Phone : +420-323-649201, ext. 361 *
*  Stellar Department                         +420-323-620361           *
*  Astronomical Institute AS CR       Fax   : +420-323-620250           *
*  251 65 Ondrejov                    e-mail: skoda at sunstel.asu.cas.cz  *
*  Czech Republic                                                       *
*************************************************************************