DataLink version identifier

[mbtaylor]

Section 2.2 says:

Operators still wishing to declare {links} endpoints can do this by giving a capability with a standardID of ivo://ivoa.net/std/DataLink#links-1.0

Versions in the VO always make my head hurt, but I think it's OK for this to still contain a "1.0" even though this is DataLink 1.1, i.e. this text is correct. Can somebody (@msdemlei?) confirm that's the case? If so, then it might be a good idea to add a comment to the text reassuring readers as clueless as me that this is not a typo.

Related: sec 3.3.1 recommends identifying output VOTables like

  <INFO name="standardID" value="ivo://ivoa.net/std/DataLink#links-1.?"/>

is that correct? I'd expect the version number in that IVOID to be the same as the one defined in section 2.2.

[msdemlei]

On Thu, Oct 21, 2021 at 03:40:45AM -0700, Mark Taylor wrote: Section 2.2 says: > Operators still wishing to declare {links} endpoints can do this by giving a capability with a standardID of `ivo://ivoa.net/std/DataLink#links-1.0` Versions in the VO always make my head hurt, but I *think* it's OK

Yeah, we entirely fouled versioning up. *Everything* about it is painful, twisted and bad.

for this to still contain a "1.0" even though this is DataLink 1.1, i.e. this text is correct. Can somebody ***@***.***?) confirm that's the case? If so, then it might be a good idea to add a comment to the text reassuring readers as clueless as me that this is not a typo.

Given we haven't told clients to match the standardID without the (minor) version, I think it'll have to say links-1.0 for the rest of Datalink 1. Any change here will break clients. Sigh.

Related: sec 3.3.1 recommends identifying output VOTables like ``` <INFO name="standardID" value="ivo://ivoa.net/std/DataLink#links-1.?"/> ``` is that correct? I'd expect the version number in that IVOID to be the same as the one defined in section 2.2.

Well. I think that isn't operationally used anywhere, and so we can say "unless you have a strong reason to do otherwise, ignore the minor version when matching against these standardID" (I think DALI would be the right place for that). When we do that, we might put the actual version there. Why we want to do that is a different matter -- what are the use cases for figuring out the minor version of the thing that produced the datalink document?

[mbtaylor]

I don't have much reason for wanting to know the minor version of a DataLink table (actually that information could be useful during validation, but that's not important enough to justify complicating other stuff). I just want it to be clear to DataLink implementors and consumers how to mark up VOTables so they can be identified as DataLink tables.

Anyway I've made a Pull Request #64 that I hope clarifies this.

[Bonnarel]

I don't have much reason for wanting to know the minor version of a DataLink table (actually that information could be useful during validation, but that's not important enough to justify complicating other stuff). I just want it to be clear to DataLink implementors and consumers how to mark up VOTables so they can be identified as DataLink tables.

Anyway I've made a Pull Request #64 that I hope clarifies this.

Will not the client have to behave differently when finding 1.1 new features ? (new PARAMS in service descriptor, content_qualifier FIELD, etc ...) ?

[msdemlei]

On Sun, Oct 24, 2021 at 12:46:46PM -0700, Bonnarel wrote: > I don't have much reason for wanting to know the minor version of a DataLink table (actually that information could be useful during validation, but that's not important enough to justify complicating other stuff). I just want it to be clear to DataLink implementors and consumers how to mark up VOTables so they can be identified as DataLink tables. > > Anyway I've made a Pull Request #64 that I hope clarifies this. Will not the client have to behave differently when finding 1.1 new features ? (new PARAMS in service descriptor, content_qualifier FIELD, etc ...) ?

Since all of these new features are optional, a client needs to individually test for them anyway, and hence it would not gain anything by knowing the generating service is version 1.1. Since this "jump-and-trip" mode is, I claim, a good idea anyway (added advantage: things will work even when 1.0 services cherry-pick individual 1.1 features), I would expect we'd recommend it even when we found some way to sneak in new mandatory features (for which peeking at the minor version number at least would work). So... I guess for the purposes of feature detection, minor version declaration isn't necessary (or even a good idea) either.

[mbtaylor]

Agree. Some of these features I was using with the hope that 1.0 services might do them anyway even before it was written in the 1.1 draft spec.

[pdowler]

Given the way we're adding new optional features, the standardID can remain unchanged and the example should say #links-1.0.