DALI 1.1 comments

[Arnold Rots]

On the ISO-8601 question of the 'Z':

FITS forbids the use of Z, for good reasons.
'Z' is really intended to provide a shorthand timezone designation,
distinguishing UTC from MET, EDT, PDT, etc.
That makes sense in a context where time is measured on the globe,
so, I guess, it makes sense for OAI.
In astronomy we have no use for timezones, but use time stamps
tied to specific time scales, one of which is UTC.
Therefore we do not need the 'Z'.
We do need to be explicit in our specification of time scale and
should attach that label to all our time stamps, implicitly or
explicitly.
Clearly, writing "2016-05-10T14:33:03Z (TDB)" would be insane.
If, therefore, the 'Z' would either be allowed or required for all
UTC time stamps, we would end up with two independent
time scale designations, which is unwise, silly, and dangerous.
Besides, the use of the 'Z' is currently prohibited by STC 1.33,
so allowing or prescribing it would require a change in an existing
standard.

Cheers,

  - Arnold

-------------------------------------------------------------------------------------------------------------
Arnold H. Rots                                          Chandra X-ray
Science Center
Smithsonian Astrophysical Observatory                   tel:  +1 617 496
7701
60 Garden Street, MS 67                                      fax:  +1 617
495 7356
Cambridge, MA 02138
arots at cfa.harvard.edu
USA
http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------------------------------------------


On Sat, May 7, 2016 at 9:15 AM, Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

> Dear DAL,
>
> Here's a list of issues I had when going through the DALI 1.1
> spec.  I'd be happy to discuss those during the upcoming meeting --
> whatever is left after that I'll happily take to the Wiki.
>
> (a) Sect 1.1: "Astronomical coordinates ... use a string
> representation... STCS" -- I don't think that sentence is true any more.
>
> (b) Sect 1.1, in particular Fig. 1: Since it seems extremely unlikely to
> me that there will be a utypes standard after all, I don't think it
> should be mentioned here.  As to what this actually means, I'd say the
> use of utypes is implied by VOTable just as, perhaps INFO items or UCDs.
>
> (c) Sect 1.1, "A registry extension schema..." -- I think this should
> reference VOResource rather than VODataService.
>
> (d) Sect 2.3: I'm almost totally sure the DALI vocabulary URI should
> *not* be an ivoid.  Rather, it should be a normal IVOA vocabulary URL,
> as in Datalink (so, here, I'd say http://www.ivoa.net/rdf/examples).
>
> In particular, whatever the base URL ends up being, it should not
> include a fragment identifier, because RDFa IIRC says the fragment
> identifier is used to complete term URIs (so, we'd have
> ivo://ivoa.net/std/DALI#examples#capability; that might even work out,
> but it's certainly a pain).
>
> (e) I'd take the XML into separate files included in the TeX document
> (\lstinputlisting) -- you could have a make target then that validates
> these files then.  If anyone asks me to, I'd do this.
>
> (f) 2.6, "the current VOSI-tables ... scalability issues" -- since it's
> not clear what "current" will be by the time this goes to REC, I'd
> suggest writing "VOSI 1.0 has scalability issues with the tables
> endpoint [and perhaps: fixed in VOSI 1.1]".
>
> (g) 3.3.3, the time format -- the thread starting at
> http://mail.ivoa.net/pipermail/grid/2016-March/002817.html
> convinced me that indeed we want the explicit annotation of the UTC
> timezone (as in "Z").  Do people strongly disagree?  I think the aspect
> of the FITS precedent was not brought up in that thread, so that might
> be an argument to drop it.  On the other hand, in Registry, OAI-PMH has
> the Z, so for us requiring the Z would be a good thing.  The pattern
> would net be
>
>   YYYY-MM-DD['T'hh:mm:ss[.SSS]'Z']
>
> Additionally, there's a redactional change further down (strike 'Values
> never...', drop the paragraph "Note that...").
>
> (h) 3.3.7 Polygon options: Lazy bum that I am, I'd make this dependent
> on whether we can fix pgSphere to do what's mathematically probably
> sounder (Option 1) rather than what it does right now (which is, I
> think, fairly close to Option 2).  Either way, this could be a good
> point to stress that services are not expected to handle polygons of
> arbitrary sizes (or are they?) and that standards using polygons in
> queries should probably have some way to say what the limit is there
> (I suspect this needs to be added to SimpleDALRegExt 1.1).
>
> (i) 3.4.4 says that MAXREC=0 has to include an overflow indicator.
> While I am not overly concerned with this, what's the rationale there?
> I'd say the metadata response is so much of a special case anyway that
> the overflow indicator would probably be more confusing than helping --
> in particular when there, indeed, would be no matching result.
>
> (j) 3.3.4 says "The service may perform validation and may try to
> execute the request, in which case a MAXREC=0 request can fail." -- that
> I think is not a good idea.  I think MAXREC=0 should be available to do
> reliable and simple parameter discovery, as it right now is in SIAP and
> SSAP (with FORMAT=Metadata, but never mind that).  Having to worry about
> putting in valid parameters certainly doesn't help there.
>
> With the current wording, a client just wanting to discover the
> parameters would have to guess what required parameters there are for a
> service (e.g., POS/SIZE for SIAv1, but for a given service there could
> be even more).  Absent those, a service might raise an error, and the
> client has no way to figure out the metadata.
>
> I think the text is trying to merge the metadata discovery use case with
> a pre-flight request use case ("will this work?").  I don't think that
> can work without ruining it for both.  If we feel we need the pre-flight
> thing (full disclosure: I don't), we should introduce a different
> feature for that.
>
> (k) 3.4.5 says: "Services may limit the size and number of uploaded
> resources; if the service refuses to accept the upload, it must respond
> with an error as described in Section 4.2."  While this is clear enough
> in the sync case, I'm not sure this exhaustively specifies what to do in
> the async case.  Should the entire job fail with a bad upload?  What if
> the upload was done in a separate request?  If a failed upload was part
> of a post to parameters and it does not trash the entire job, should any
> other parameter posted be set or not?  All this is complicated enough
> that I think we should, at this point, say "When an upload to an async
> job fails, behaviour is undefined (except that the job must still be
> deletable, obviously)."
>
> (l) 4.1 says "after zero or more redirects", and I wonder if there
> should be a limit as to how many redirects a client has to accept.  You
> see, if the acceptance of arbitrarily many redirects is a validity
> criterion, valid clients can never get out of a redirect loop.  And
> these things happen more often than you'd think.
>
> Can we agree to language like "clients are not required to follow more
> than x redirects"?  For x, I'd propose 2 (which should do for
> "technical" redirects) or 16 (which might do for pseudo-sync over what's
> really async -- beyond that, you probably should go all the way to
> async).
>
> Whatever we do about this, it would need to be reflected in Sect. 4.3
> (and perhaps 4.1 should just reference that?)
>
> Cheers,
>
>           Markus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20160510/ab6e32c7/attachment.html>