request to modify VODataService schema

[Patrick Dowler]

Within our TAP service code, we do store ID values for columns that can be
referenced (by service descriptors) and they are unique within that context.
The presence of an ID is an indicator that the column has an associated service
descriptor.

However, right now a caller can see which columns have ID values
assigned if they
get a VOTable description, but not if they get a VOSI-table
description. I would like
those two descriptions to be equivalent.... I prefer to consider VOSI-table (aka
VODataService) as the definitive model for tables and I really want to
avoid the
scenario where it is a second-class serialization, but I cannot convey
the column ID
value in the VOSI-table document.

For the VOSI-tables mechanism where users create tables, we actually
want to enable
the user to assign an ID to a column and/or see what ID is assigned so
they can define
a service descriptor the service would inject into results. This is
custom behaviour of our
service and I'm not suggesting it would be required behaviour (eg if
someone creates a
table from VOTable and one or more fields have ID attributes).

To be fair, this does not have to be an xs:ID and I think your points
about the larger registry
context are a good argument for it not being an xs:ID, so just a
simple string identifier would
suffice. We considered trying to keep ID usage completely internal and
uniquely identifying
a column via the name (fully qualified table name + column name) but
parsing that is a little
under specified since we advise treating table name as opaque and all
the complications
with quoted identifiers... ugh. Which led us back to wanting a clean
column ID that is unique
within that TAP service.

Another option would be to include a single "xs:any" child element in
the column (and table)
element so that implementations could embed some additional supporting
metadata. I would
only see this being used in protocol interactions between a client and
the VOSI-tables endpoint
and not something one would include in registry records.
--
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada

On Mon, 9 Dec 2024 at 01:16, Markus Demleitner via registry
<registry at ivoa.net> wrote:
>
> Hi Pat,
>
> On Fri, Dec 06, 2024 at 12:53:38PM -0800, Patrick Dowler via registry wrote:
> > The item that I am currently running into is the ID (type="xs:ID")
> > attribute on field elements, which in VOTable are used with DataLink
> > service descriptors in ref attributes. So, when you query a service
> >
> > The use case is in the context of WD-TAP-1.2 where we are extending
> > VOSI-tables to allow users to create tables; we support both formats
> > and want to enable users to assign an ID to columns/fields and we want
> > both formats to be equivalent.
> >
> > Thoughts?
>
> Hm... I don't think I understand the intention of the addition,
> really.  Are you saying you are storing the FIELD IDs somewhere?  To
> me, they are necessarily serialisation details *of a concrete
> VOTable*.  Otherwise, you would have to somehow ensure all the
> FIELD IDs are unique across all your TAP-published tables, since you
> never know when someone does a join between two tables that happen to
> have FIELDs with the same ID.
>
> A similar consideration applies to VODataService tablesets, by the
> way.  When you dump these into a registry record or /tables response
> and there are multiple column elements with the same ID... does that
> mean anything?  If it does not mean anything, why have these IDs in
> the first place?
>
>
> As an aside, I note that there *have* been requests for id/idref
> pairs in VOResource, in particular to join tables and services
> operating on them.  This is a similarly costly endeavour because you
> would have to be very careful managing ids when assembling OAI-PMH
> responses.  This has already been a really painful issue when people
> embedded STC-X in resource records for a while, because these
> usually came with a lot of ids that somehow needed to be
> disambiguated by all components of the Registry ecosystem.  Ouch!
>
> I give you that does not *really* apply here.  But again: if there
> are no uniqueness requirements on ID, what is it good for?
>
>            -- Markus
>