IVOA Support Interfaces 1.1

[Markus Demleitner]

Dear GWS,

On Fri, Jun 19, 2015 at 10:05:59AM +0200, Marco Molinaro wrote:
> Then, I have no specific preference on the choice. I thought I'd
> prefer 1, but I'm not sure.
> I think that the change in the /tables endpoint comes out of TAP
> revision mainly, and probably is related to whether we want to expose
> actual tablesets or structured tables inside some hierarchy.
> My feeling is that the use cases are more for tables collected, less
> for how they are organized in catalog.schema.* solutions.

Right -- also note that VOSI tableset is used in many single-table
services like our S-protocols, and for those schema is particularly
artificial.

> So, if we think the model is flawed, probably it's better to fix it.
> However this means asking providers to change their XML outputs...and
> that is a major thing...that's why I'm probably ok whatever the
> majority of involved parties choose.

I don't think I'd outlaw the schema element; essentially, we'd just
re-allow having  tables directly in the tableset (a bit like it was
in VODataService 1.0, except avoiding the mistakes made in that
initial draft).  Doing that also makes a lot of sense since it's
called tableset and not schemaset :-).  Whatever is legal now will
remain legal under that scheme.

Then Kristin said:

> We have a service with multiple MySQL-databases (schemas), and many tables for
> each of them. So I would want to have the possibility to just list the schemas
> (without all the tables) and also filter by schema (listing tables for just
> one schema).

I'm still trying to find a good example in which having an extra
level of indirection actually has an advantage.  It doesn't for sites
like VizieR (where listing the four schemas is relatively pointless,
and each schema won't be noticeably smaller than the full thing), and
it doesn't for sites like us (where we have about as many schemas as
tables, so /tables/schema wouldn't be much simpler than /tables
itself if we allow empty table bodies).

Maybe yours is one -- it sounds as if the cardinality of both /schema
and each /schema/tables would comparable, and the (by itself
desirable) log-decrease in cardinalities actually happens.

Another possible extra benefit would be if there's significant
metadata hanging on the schema that people might want to separately
retrieve.  In tableset, that's mainly the table descriptions (schema
description, ucd, utype would probably available top-level, right?).
In hierarchical schema browsing, I can see there can be a benefit
there, but again I feel including this table metadata top-level will
not significantly compromise scaleability.

That has to be weighed against the certainty that all of <tablename>,
<schema>.<tablename> and <catalog>.<schema>.<tablename> will have to
be shoehorned into the /<schema>/<tablename> URL schema.  This
shoehorning will presumably get worse as other query languages will
be transported through TAP.

Hence, again, I offer my unsolicited opinion: Let's not encode things
in our URL schemes that we're not really confident are true and will
remain true unless we identify compelling reasons to do so.

Cheers,

              Markus