WD-DALI-1.1-20160415
Mark Taylor
M.B.Taylor at bristol.ac.uk
Mon May 16 17:19:13 CEST 2016
Hi Pat/DAL,
I already voiced my concerns about the endpoint changes in this DALI
version, here I list some more trifling concerns on this draft:
sec 2:
If sync, async and tables endpoints can be securityMethod-specific
(ignoring for now that I'm not a huge fan of that) then why not
examples? The possible example queries may well be dependent
on authorization.
sec 2:
In section 2 it says:
"All DALI and VOSI-tables resources must be siblings of the
VOSI-capabilities resource, but concrete service specifications
should not constrain the names of these resources further."
but sec 2.1 and 2.2 say (of async and sync endpoints respectively):
"A concrete DAL service specification ... may mandate a specific
resource name to support simple client use"
I'm not sure if a "should not" and a "may" are strictly in
contradiction, but this sounds to me like mixed messages about
best practice.
sec 2.3.3 and 2.3.4:
The examples include a REQUEST=doQuery generic-parameter.
Since this is no longer recommended usage in TAP 1.1, remove it?
sec 2.3.4:
The property="continuation" link elements in the example have
no @resource attribute, but the text says they are supposed to
have empty @resource attributes.
sec 3.3:
The introductory text here says that the literal representations
described are "as parameter values when invoking simple services,
as data values in response documents (e.g. VOTable), etc.".
However the text in 3.3.[12] says values must be represented
as described by the XSD standard. That's OK for name=value
specifications (a la application/x-www-form-urlencoded),
but not when the values are in a VOTable, since VOTable has
its own rules about integer/floating-point/boolean value encoding,
similar but not identical to XSD. The text should be adjusted
to make clear that the XSD-alike prescriptions here don't apply
to VOTable content.
To confuse matters further ... by my reading of
https://www.w3.org/TR/xmlschema11-2/ sec 3.3.5.2, one instance
in which XSD representation of floating point values differs from
that of VOTable is when it comes to infinities: it's "+Inf"/"-Inf"
in VOTable but "+INF"/"-INF"/"INF" in XSD. That means that
the examples in sec 3.3.4 would look different whether they
are in name=value parameter specifications or a VOTable TD/PARAM.
Actually as written they don't quite work for either: "Inf" is
not legal in either case.
Would it be easier to follow VOTable rules in all cases?
sec 3.3.7:
I don't like mandating arraysize="*"; in a given case you might
want to set it to a fixed value.
I also fixed some tiny typos at r3402.
Mark
On Thu, 14 Apr 2016, Patrick Dowler wrote:
> I have just committed rev 3302
>
> Diff from previous:
> https://volute.g-vo.org/viewvc/volute/trunk/projects/dal/DALI/DALI.tex?r1=3251&r2=3302
>
> For those that like a complete document over latex diffs, I put a pdf
> on the DALI Next page:
> http://wiki.ivoa.net/internal/IVOA/DALI-1_0-Next/WD-DALI-1.1-20160415.pdf
>
> Changes:
>
> * Expanded section on intervals to allow use of all integer and
> floating point datatypes
> supported by VOTable; only floating point intervals support open-ended
> intervals.
> * Expanded section on geomery to allow use of datatype="float" in
> addition to double.
> * Removed all restrictions on the resource name and location for
> VOSI-availability.
> * Removed restriction on the resource name of VOSI-tables.
> * Fixed the timestamp format specification to correctly specify optional parts.
> * Added reference to RFC2616 and minimised discussion of HTTP headers.
>
> Right now, intervals are defined strictly with arraysize="2" pending
> some discussion in the other thread on whether to support "2*"...
> please keep the discussion of this topic over there. where the context
> is.
>
> --
> Patrick Dowler
> Canadian Astronomy Data Centre
> Victoria, BC, Canada
>
--
Mark Taylor Astronomical Programmer Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776 http://www.star.bris.ac.uk/~mbt/
More information about the dal
mailing list