VOTable 1.5 Working Draft (2023-09-13)

[Tom Donaldson]

Dear Markus and François,

I am following this discussion with interest, but only wish to comment on the suggestion to use GROUPs for this purpose.

In my reading of the GROUP specification, it is too general to be used unambiguously among provider and consumers who have only read the VOTable spec.  GROUPs do supply a very good mechanism for peers to convey mutually agreed upon information, but since that requires mutual understanding of non-public conventions, it cannot be reliably interoperable.  I'd be happy to be proven wrong here, but as Markus points out, without an agreed-upon standard or convention, there is guesswork in both providing and consuming this content.  To me such guesswork is not suitable for interoperability.

.
.
.
   > > That's exactly the discussion I was referring to, this change is a
   > > transformation of COOSYS into a specialized GROUP. But I can't
   > > understand why the code would be more complex if you have the
   > > relationship referenced in a GROUP rather than in a COOSYS playing
   > > the GROUP's role ?
   >
   >
   > For the writer: You have to manage still another id-ref relationship,
   > with all the usual uglyness: Come up with an id, make sure it's
   > document-unique, make sure it stays that way when you merge VOTables,
   > and so on.
   >
   >
   > For the reader: You have to locate the group(s) that happen to link
   > COOSYS and the other elements (i.e., tell it from all kinds of other
   > groups that may be in a VOTable), and then follow the id-ref
   > relationship to the COOSYS the writer had to worry about in the first
   > place, handling all the possible errors that may happen (no element
   > with that ID, the element isn't a COOSYS, etc).
   >
   >
   > Yes, that's not rocket science, but it's not entirely trivial code
   > either, with many error conditions and corner cases to catch. *If*
   > we actually improved matters by doing this, I might be willing to
   > write that code. But at this point I still don't see a practical
   > problem that introducing this intermediate GROUP would fix. Perhaps
   > if you tried again to explain the danger you perceive with forward
   > referencing?

In my reading of the GROUP specification, it is too general to be used unambiguously among providers and consumers who have only read the VOTable spec.  GROUPs do supply a very good mechanism for peers to convey mutually agreed upon information, but since that requires mutual understanding of non-public conventions, it cannot be reliably interoperable.  I'd be happy to be proven wrong here, but as Markus points out, without an agreed-upon standard or convention, there is guesswork in both providing and consuming this content.  To me such guesswork is not suitable for interoperability.

.
.
.