Standard IVORNs, data model identifiers

[Markus Demleitner]

Dear Colleagues,

I seem to run into IVORN related gotchas with alarming regularity
these days, I'm afraid.  Really sorry about this.

Well, this time it's about StandardsRegExt and data model ids in
TAPRegExt.  At the root of the problem is that I foolishly declared
the ivo-id attribute on dataModel as vr:IdentifierURI (rather than
xs:anyURI).  vr:IdentifierURI doesn't allow fragments, though.

Why is that bad?  Well, what do these identifiers reference?  Why,
resource records of course.  No, not quite.  With StandardRegExt, the
idea is to register a standard more or less like this:

<ri:Resource xsi:type="vstd:Standard" ...>
  ...
  <endorsedVersion status="rec">1.1</endorsedVersion>
  <endorsedVersion status="wd">2.0</endorsedVersion>
  <deprecated>1.0</deprecated>
</ri:Resource>

After that, I thought it'd be clever to reference these version
entities in there, for which there is the fragment identifier.
Hence, version 1.0 of RegTAP would have been

  ivo://ivoa.net/std/RegTAP#1.0

I'd have liked that a lot, so I went ahead, put that change into my
relational registry implementation, from where it went into
TAPRegExt's dataModel and boom! This is not an IdentifierURI, service
invalid.

This is not (only) about URI cosmetics. These identifiers are
important for locating TAP services supporting, e.g., obscore, the
relational registry, and more in the future.  How important is
versioning in that process?

The answer will determine which of the two exits I can see is
preferable:

(a) have unversioned standard identifiers in dataModels (and possibly
other places like standardIDs) henceforth, i.e.,
ivo://ivoa.net/std/RegTAP -- that kinda works as long as the standard
evolves smoothly enough and we make a new record for a new major
version ("std/RegTAP2").  But then there's no machine-readable way of
figuring out the version actually found on the other end, which is
probably not good.

(b) go on as we have so far and create a new standards record for
every (even minor) version that we need in standardIDs and similar
places.

On a longer run, we might want to fix VOResource to allow fragment
identifiers in IdentifierURIs, but that's not an option right now.  I
need to put the id people should be looking for into the RegTAP
document now.

My feeling is that (a) would be nicer in priciple, but it would be
basically impossible for a client to use any features introduced  in
point versions.  That would throw us back to (b) with the implied
inflation in records.

Opinions?  Elegant solutions, anyone?  Please?

Cheers,

          Markus