VOResource 1.1: IdentifierURI

[Patrick Dowler]

I think I would like  to use xs:anyURI for things like standardID
(maybe most things) and I would want to have something like
RegistryReference for those cases where that is specifically required.
Note that one of the securityMethod/@standardID values is a non-ivo
uri in SSO-2.0; I caused that by using that URI in a VOSI-capabilities
document and it is currently valid (already xs:anyURI?). I think one
could find non ivo URIs for other securityMethods in that doc. So that
is mostly like #1.

As for why I'd like standardID to be xs:any? If I have a custom
capability I would like the VOSI-capabilities to have a capability and
I would use the standardID with a non-ivo URI (which an industrious
user/client could follow to find documentation). Being able to do that
allows us to use capabilities to more loosely couple clients and
services but still find the desired service/interface/securityMethod
in the normal way for both standard and custom services. I think it is
an important feature to be able to use the VO for your custom
stuff.... hence standardID should be xs:anyURI.

If you want to improve the clarity of names then deprecating
IdentifierURI and introducing RegistryReference could be done, but
could be considered a separate issue.

my 2c,


On 5 July 2016 at 07:27, Markus Demleitner
<msdemlei at ari.uni-heidelberg.de> wrote:
> Dear Registry WG,
>
> Next up on my list of things to discuss in the run-up to VOResource
> 1.1 is IdentifierURI.  That's a type that in 1.0 is locked down to
> essentially IVOIDs without query or fragment parts[1]; in Identifiers
> 2.0 language, that's a "registry reference", and it was probably
> intended to be just that: A reference to a registry record.
>
> It's used in places like Resource/identifier, capability/@standardID,
> ResourceName/@ivo-id, and validation/@validatedBy. Also, TAPRegExt 1.0's
> dataModel was an IdentifierURI, which hurt me a lot.
>
> So, it's become a problem.  The reason is that in some of these
> places, there should now be more general references.  In particular,
> versions of standards eventually turned out to be parts of resource
> records rather than separate resource records.  This means that we
> now have standardIDs like ivo://ivoa.net/std/tap#query-1.1.  Which
> are IVOA identifiers just fine but don't match IdentifierURI.
>
> So, how can we fix this?  I see a couple of ways:
>
> (1) Leave IdentifierURI as is (well, fixing the case-insensitive ivo)
> and re-define everything that can have non-simple IVOIDs to be
> xs:anyURI.  TAPRegExt/dataModel already went this way in 1.1. In
> VOResource, we'd probably just have to touch
> vr:Capability/@standardID.  Advantage: it's not very invasive.
> Disadvantage: the name IdentifierURI is wrong, because the schema is
> far more restrictive than actual IVOIDs are.
>
> (2) Change IdentifierURI to actually allow at least as much as
> Identifiers 2.0 does.  Introduce a new type (RegistryReference, say)
> that would be essentially the current IdentifierURI.
> Resource/identifier, ResourceName/@ivo-id and perhaps
> validation/@validiatedBy would then become RegistryReferences.
> Advantage: to my taste, that's the cleanest solution.  Disadvantage:
> It's quite intrusive, and it changes IdentifierURI, which is/was used
> in registry extensions, so we're  "liberalising" some other
> schemas, too (which may be what we want, but it's still fishy).
>
> (3) Deprecate IdentifierURI and define RegistryReference as above.
> Then, in addition, define  IVOID, say, which allows for full identifiers.
> Advantage: as (2), but avoids collaterally changing other schemas.
> Disadvantage: Deprecated definitions hanging around.  And it's as
> intrusive as (2).
>
> (4) Deprecate IdentifierURI and just allow xs:anyURI whereever there
> is now IdentifierURI.  Advantage: in effect, it's a simplifiation;
> also, for quite a few of IdentifierURI uses there's no terribly
> strong reason why the Registry should play a role at all (e.g.,
> standardID), so perhaps allowing whatever URIs people want to use is
> even the right thing to do.  Disadvantage: In Resource/identifier,
> which architecturally must be a Registry reference (since the primary
> key is built from it), we have no syntactic guarantees any more that
> what we're dealing with is an IVOA identifier.
>
> So... Does anyone have preferences to one side or another?  Or
> perhaps even other solutions?
>
> Me, I'm currently leaning towards (2); hence, if you don't like (2),
> you should speak up (even if you hate the other alternatives, too).
>
> Cheers,
>
>            Markus
>
>
> [1] In case you're curious: it's this wonderful RE:
> ivo://[\w\d][\w\d\-_\.!~\*'\(\)\+=]{2,}(/[\w\d\-_\.!~\*'\(\)\+=]+(/[\w\d\-_\.!~\*'\(\)\+=]+)*)?
> -- which is probably not right because the scheme must be
> case-insenstive (as it is for all URIs).



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