Discovering Data Collections Note

[Patrick Dowler]

Hmm, OK I see the problems with how queries are done...

But stepping back, I have to say I am not really a fan of documents
other than the standard defining these. Basically,
ivo://ivoa.net/std/TAP#sync-1.1 says that the concept of sync-1.1 is
defined in that standard.... so ivo://ivoa.net/std/TAP#sync-aux-1.1
would be a big fat lie unless sync-aux-1.1 is defined in that
standard. It goes right back to basic resolving of URIs and fragments
that we have discussed before. So maybe you have convinced me (or I've
convinced myself) that standards do need to define the aux
standardID(s) themselves... with advice and usage endorsed by this
note. The side effect of that is that there is no requirement to be
able to parse or separate those keys as they are an enumeration in the
standard, so then the values can be crafted to make usage (in RegTAP)
convenient.

I can see the value in the aux standardIDs, and I am currently looking
at 20 CADC data collections where I would add various aux capabilties:
 TAP for all, SIA for a subset of those, and one or two that also have
VOSpace capabilites.

Pat

PS-Could we request/issue errata to add aux standardID(s) to existing
standards as they are needed (eg the vospace example above) rather
than wait until the next version?

On 8 November 2016 at 02:28, Markus Demleitner
<msdemlei at ari.uni-heidelberg.de> wrote:
> Dear Registry community,
>
> Sorry for replying to myself, but as soon as my brain got a bit of
> extra air, I remembered what had worried me yesterday at this point:
>
> On Mon, Nov 07, 2016 at 10:16:56AM +0100, Markus Demleitner wrote:
>> > groovy:000> new URI("ivo://ivoa.net/std/SIA#query-2.0;aux").getFragment()
>> > ===> query-2.0;aux
>>
> [...]
>> Postfixing the aux is less problematic, and might even make
>> version-constrained queries easier.  I'd have to see if there's any
>> hidden pitfalls if people really liked them a lot better.
>
> The pitfall is actually not terribly hidden.  By Identifers 2.0
> (http://www.ivoa.net/documents/IVOAIdentifiers/20160523/REC-Identifiers-2.0.html#tth_sEc4.2),
> "normal" service discovery with new-style, versioned ids should be by
> matching
>
>   standard_id LIKE 'ivo://ivoa.net/std/exampleProto#query-1.%'
>
> (or equivalent); this is because a version 1 client should be able to
> operate all of 1.0, 1.1, 1.2, etc., and hence should also try to
> discover all of them.
>
> When you postfix the aux, these clients will immediately get all
> auxiliary capabilities, which typically they won't want.  Worse,
> writing "no auxiliary capabilities, please" (the enumeration use
> case) really becomes ugly even if you're aware that auxiliary
> capabilities might come your way; current IVOA versioning rules say
> that version strings might look like 1.04, so "query-1._" isn't safe.
>
> We could say we should restrain versions to just major.minor (and
> you'd have my vote), but enabling postfixing the -aux doesn't sound
> like a strong reason for that.
>
> Lest I forget that again, I've added a rationale for the chosen
> identifier form in 2.1.2 for the PEN draft (Volute rev. 3697);
> formatted on http://docs.g-vo.org/discovercollections.pdf.
>
> The new text is, roughly:
>
>   This particular form for the protocol identifier is chosen to work
>   well with the intended way to discover services with such new-style
>   standard identifiers. As discussed in sect. 4.2 of the Identifiers
>   standard, services supporting the major version n of the protocol std
>   would query for, using SQL patterns,
>
>   ivo://ivoa.net/std/std/tag-n.%,
>
>   where the wildcard allows the simultaneous discovery of all minor
>   versions. This is the intended behaviour, since by IVOA versioning
>   policies a client for version n should be able to operate all of n.0,
>   n.1, and so on.
>
>   If auxiliary ids were built by appending the -aux, this pattern would
>   match auxiliary capabilities as well, thus making the enumeration use
>   case extremely cumbersome to cover. Prepending the aux-, on the other
>   hand, would require embedded wildcards in the pattern of the data
>   discovery use case - where both primary and auxiliary capabilities
>   should be investigated while protocol versions are typcially a
>   secondary concern -, which at the very least is an efficiency
>   concern. See sect. 2.2 for the recommended discovery patterns.
>
> This certainly is another hindrance on the way of the whole document
> to the short list to the Pulitzer Prize, but frankly, my hopes in
> that direction had be modest even before.
>
>        -- Markus



-- 
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada