request to modify VODataService schema

[Markus Demleitner]

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