DALI 1.1 comments

[Markus Demleitner]

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