VODataService 1.2, PR ready for RFC?

[Mark Taylor]

Markus,

On Fri, 19 Jul 2019, Markus Demleitner wrote:

> I've uploaded VODataService PR-2019-07-15 to the document repository
> -- http://www.ivoa.net/documents/VODataService/20190715/ --, and this
> is what I hope will go on to RFC.  So, I'd be very grateful if
> whoever authors resource records or generates VOSI tables documents
> could have a look at it now.

no major comments, but a few minor ones:

  - sec 2.1: "As recommend by" -> "As recommended by"

  - sec 2.2.4: "historical excurse" -> "historical excursion"

  - sec 3.1.3: "descre a resource" -> "describe a resource"

  - sec 3.1.3: "declare of the metadata" -> "declare the metadata"?

  - sec 3.2, footnote 4: "Version 1.1 of MOC will give a normative
      specification of ASCII MOCs, which is expected to exactly
      match the non-normative proposal in version 1.0.":
      The current MOC 1.1 draft doesn't *exactly* match the non-normative
      proposal from MOC 1.0 (e.g. the MOCORDER may be provided in 1.1,
      but not 1.0).  Maybe by the time that VODataService 1.2
      gets close to REC MOC 1.1 will be accepted, in which case the
      reference can just be made to MOC 1.1, but until then, just
      remove the term "exactly"?

  - sec 3.2: the first item in the list of Elements on p.21, with
      Meaning "An STC 1.0 description..." doesn't seem to have
      an element name or a Type value.

  - sec 3.2: the "string of the form [horrible regex]" Type entries
      for the temporal and spectral elements are almost unreadable
      by humans (or at least by me).  I suspect this text is
      autogenerated from the XSD (in fact I vaguely remember making
      this complaint before), but is there any chance of replacing
      it with something more digestible?  If not, at the very least
      add an example in a Comment for temporal as has been done for
      spectral.

  - sec 3.3: "may provide access several" -> "may provide access to several"

  - vs:Table XSD: should the @type for the nrows element be
       xs:nonNegativeInteger instead of xs:integer?
       But I don't suppose in practice that would capture any
       genuine errors, so if there's some preference for less-obscure
       datatypes I certainly wouldn't insist.

  - sec 3.5.1: "paramter" -> "parameter"

  - sec 3.5.1: The vs:InputParam attributes @use Allowed Values
      lists the value "optional" twice.

  - References: the Discovering Data Collections Note appears twice
      in the bibliography.
   
Mark

--
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/