<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div>On the ISO-8601 question of the 'Z':<br><br></div>FITS forbids the use of Z, for good reasons.<br></div>'Z' is really intended to provide a shorthand timezone designation,<br></div>distinguishing UTC from MET, EDT, PDT, etc.<br></div>That makes sense in a context where time is measured on the globe,<br></div><div>so, I guess, it makes sense for OAI.<br></div>In astronomy we have no use for timezones, but use time stamps<br></div>tied to specific time scales, one of which is UTC.<br></div><div>Therefore we do not need the 'Z'.<br></div>We do need to be explicit in our specification of time scale and<br></div>should attach that label to all our time stamps, implicitly or<br></div>explicitly.<br></div>Clearly, writing "2016-05-10T14:33:03Z (TDB)" would be insane.<br></div>If, therefore, the 'Z' would either be allowed or required for all<br></div>UTC time stamps, we would end up with two independent<br></div>time scale designations, which is unwise, silly, and dangerous.<br></div>Besides, the use of the 'Z' is currently prohibited by STC 1.33,<br></div>so allowing or prescribing it would require a change in an existing<br></div>standard.<br><br></div>Cheers,<br><br></div> - Arnold<br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">-------------------------------------------------------------------------------------------------------------<br>Arnold H. Rots Chandra X-ray Science Center<br>Smithsonian Astrophysical Observatory tel: +1 617 496 7701<br>60 Garden Street, MS 67 fax: +1 617 495 7356<br>Cambridge, MA 02138 <a href="mailto:arots@cfa.harvard.edu" target="_blank">arots@cfa.harvard.edu</a><br>USA <a href="http://hea-www.harvard.edu/~arots/" target="_blank">http://hea-www.harvard.edu/~arots/</a><br>--------------------------------------------------------------------------------------------------------------<br><br></div></div></div>
<br><div class="gmail_quote">On Sat, May 7, 2016 at 9:15 AM, Markus Demleitner <span dir="ltr"><<a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank">msdemlei@ari.uni-heidelberg.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear DAL,<br>
<br>
Here's a list of issues I had when going through the DALI 1.1<br>
spec. I'd be happy to discuss those during the upcoming meeting --<br>
whatever is left after that I'll happily take to the Wiki.<br>
<br>
(a) Sect 1.1: "Astronomical coordinates ... use a string<br>
representation... STCS" -- I don't think that sentence is true any more.<br>
<br>
(b) Sect 1.1, in particular Fig. 1: Since it seems extremely unlikely to<br>
me that there will be a utypes standard after all, I don't think it<br>
should be mentioned here. As to what this actually means, I'd say the<br>
use of utypes is implied by VOTable just as, perhaps INFO items or UCDs.<br>
<br>
(c) Sect 1.1, "A registry extension schema..." -- I think this should<br>
reference VOResource rather than VODataService.<br>
<br>
(d) Sect 2.3: I'm almost totally sure the DALI vocabulary URI should<br>
*not* be an ivoid. Rather, it should be a normal IVOA vocabulary URL,<br>
as in Datalink (so, here, I'd say <a href="http://www.ivoa.net/rdf/examples" rel="noreferrer" target="_blank">http://www.ivoa.net/rdf/examples</a>).<br>
<br>
In particular, whatever the base URL ends up being, it should not<br>
include a fragment identifier, because RDFa IIRC says the fragment<br>
identifier is used to complete term URIs (so, we'd have<br>
ivo://<a href="http://ivoa.net/std/DALI#examples#capability" rel="noreferrer" target="_blank">ivoa.net/std/DALI#examples#capability</a>; that might even work out,<br>
but it's certainly a pain).<br>
<br>
(e) I'd take the XML into separate files included in the TeX document<br>
(\lstinputlisting) -- you could have a make target then that validates<br>
these files then. If anyone asks me to, I'd do this.<br>
<br>
(f) 2.6, "the current VOSI-tables ... scalability issues" -- since it's<br>
not clear what "current" will be by the time this goes to REC, I'd<br>
suggest writing "VOSI 1.0 has scalability issues with the tables<br>
endpoint [and perhaps: fixed in VOSI 1.1]".<br>
<br>
(g) 3.3.3, the time format -- the thread starting at<br>
<a href="http://mail.ivoa.net/pipermail/grid/2016-March/002817.html" rel="noreferrer" target="_blank">http://mail.ivoa.net/pipermail/grid/2016-March/002817.html</a><br>
convinced me that indeed we want the explicit annotation of the UTC<br>
timezone (as in "Z"). Do people strongly disagree? I think the aspect<br>
of the FITS precedent was not brought up in that thread, so that might<br>
be an argument to drop it. On the other hand, in Registry, OAI-PMH has<br>
the Z, so for us requiring the Z would be a good thing. The pattern<br>
would net be<br>
<br>
YYYY-MM-DD['T'hh:mm:ss[.SSS]'Z']<br>
<br>
Additionally, there's a redactional change further down (strike 'Values<br>
never...', drop the paragraph "Note that...").<br>
<br>
(h) 3.3.7 Polygon options: Lazy bum that I am, I'd make this dependent<br>
on whether we can fix pgSphere to do what's mathematically probably<br>
sounder (Option 1) rather than what it does right now (which is, I<br>
think, fairly close to Option 2). Either way, this could be a good<br>
point to stress that services are not expected to handle polygons of<br>
arbitrary sizes (or are they?) and that standards using polygons in<br>
queries should probably have some way to say what the limit is there<br>
(I suspect this needs to be added to SimpleDALRegExt 1.1).<br>
<br>
(i) 3.4.4 says that MAXREC=0 has to include an overflow indicator.<br>
While I am not overly concerned with this, what's the rationale there?<br>
I'd say the metadata response is so much of a special case anyway that<br>
the overflow indicator would probably be more confusing than helping --<br>
in particular when there, indeed, would be no matching result.<br>
<br>
(j) 3.3.4 says "The service may perform validation and may try to<br>
execute the request, in which case a MAXREC=0 request can fail." -- that<br>
I think is not a good idea. I think MAXREC=0 should be available to do<br>
reliable and simple parameter discovery, as it right now is in SIAP and<br>
SSAP (with FORMAT=Metadata, but never mind that). Having to worry about<br>
putting in valid parameters certainly doesn't help there.<br>
<br>
With the current wording, a client just wanting to discover the<br>
parameters would have to guess what required parameters there are for a<br>
service (e.g., POS/SIZE for SIAv1, but for a given service there could<br>
be even more). Absent those, a service might raise an error, and the<br>
client has no way to figure out the metadata.<br>
<br>
I think the text is trying to merge the metadata discovery use case with<br>
a pre-flight request use case ("will this work?"). I don't think that<br>
can work without ruining it for both. If we feel we need the pre-flight<br>
thing (full disclosure: I don't), we should introduce a different<br>
feature for that.<br>
<br>
(k) 3.4.5 says: "Services may limit the size and number of uploaded<br>
resources; if the service refuses to accept the upload, it must respond<br>
with an error as described in Section 4.2." While this is clear enough<br>
in the sync case, I'm not sure this exhaustively specifies what to do in<br>
the async case. Should the entire job fail with a bad upload? What if<br>
the upload was done in a separate request? If a failed upload was part<br>
of a post to parameters and it does not trash the entire job, should any<br>
other parameter posted be set or not? All this is complicated enough<br>
that I think we should, at this point, say "When an upload to an async<br>
job fails, behaviour is undefined (except that the job must still be<br>
deletable, obviously)."<br>
<br>
(l) 4.1 says "after zero or more redirects", and I wonder if there<br>
should be a limit as to how many redirects a client has to accept. You<br>
see, if the acceptance of arbitrarily many redirects is a validity<br>
criterion, valid clients can never get out of a redirect loop. And<br>
these things happen more often than you'd think.<br>
<br>
Can we agree to language like "clients are not required to follow more<br>
than x redirects"? For x, I'd propose 2 (which should do for<br>
"technical" redirects) or 16 (which might do for pseudo-sync over what's<br>
really async -- beyond that, you probably should go all the way to<br>
async).<br>
<br>
Whatever we do about this, it would need to be reflected in Sect. 4.3<br>
(and perhaps 4.1 should just reference that?)<br>
<br>
Cheers,<br>
<br>
Markus<br>
</blockquote></div><br></div>