SSA-1.1

[Douglas Tody]

Petr - thanks for the careful reading.  These all look like good points
which should be considered.  Re ISO8601 we may well want to permit only
a subset in order to simplify requirements for parsers (and we probably
don't need all the permutations), however this is a broader issue than
just SSA.  Perhaps others will comment as well.   - Doug


On Tue, 15 Mar 2011, Petr Skoda wrote:

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