VODataService 1.3 PR

[Markus Demleitner]

Dear Mark,

On Tue, Jul 14, 2026 at 01:08:52PM +0100, Mark Taylor wrote:
> I made a pull request https://github.com/ivoa-std/VODataService/pull/24
> with some trivial typo corrections.

Thanks!

> Sec 1.2:
>    "As of October 2018, there are more than 20000 resources of type
>     vs:CatalogService in the VO Registry"
>       - update this statistic?

Good point.  It's now more than 31'000.  Fixed in commit 9bda7fd0.

>
> Sec 2:
>    The example contains a non-VOUnit-compliant unit element:
>
>       <unit>km/sec</unit>
>
>    I guess it would be a good idea to update this to the
>    VOUnits-compliant "km/s".

Uh, how embarrissing.  Fixed in commit 3b22dccc.

>    However, the unit element documentation within the vs:BaseParam type
>    definition in the XSD doesn't currently say anything about VOUnits.
>    Maybe it would be a good idea to reference/recommend/require
>    VOUnit compliance here?  For comparison, VOTable has said since
>    version 1.5 that unit attribute syntax SHOULD conform to VOUnits.

I've added some text to this effect in commit 260c1767.

> Sec 3.3.1:
>    "all table names within a schema element must be unique"
>
>    IIUC this is not a strong enough requirement, at least for
>    TAP-accessible tables.  Sec 3.3 says:
>
>       "When the table set describes a set of TAP-accessible tables,
>        the value of a table's name child must be in a form immediately
>        usable for use in ADQL or SQL queries."
>
>    That means in ADQL no schema qualification on top of the declared
>    table name is used when referencing a table, so to avoid ambiguity
>    then all table names in the tableset, not just within each schema,
>    have to be unique.
>
>    If this is updated, the xs:unique constraint on vs:TableSet in the
>    XSD should also be updated.

I'll refrain from this; true, with TAP/ADQL tablesets the table names
will be unique, but we may want to use tablesets for other purposes
(we've thought about VOEvent streams for a while), and then it's
likely enough if they are unique per-schema.

> Sec 2.2.2:
>     The text says concerning vs:StandardSTD and vs:DataCollection:
>
>        "If all such records have disappeared from the VO by version 1.4
>         of this specification, their type declarations may be removed
>         from the schema."
>
>     However the xs:documentation for the StandardSTC type in the XSD says:
>
>        "This resource type is deprecated, and no resource records
>         of this type exist in the Registry.  It will be removed
>         in version 1.3 of VODataService."
>
>    So either remove StandardSTC now, or otherwise update the
>    documentation in one or both places for consistency.

Right.  I frankly can't remember why I backed out of dropping
StandardSTC.  I've done it in b4b5955c.

Thanks for the review.  Can you have a look at
https://github.com/ivoa-std/VODataService/pull/25 to see whether
you're happy with my changes?

Thanks,

           Markus