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