VOResource 1.1: IdentifierURI

[Theresa Dower]

I definitely agree in the case of standardID, and, like Pat, specifically because of issues I see coming down the pipeline with different, mission/archive-prescribed authentication & authorization mechanisms. I haven't picked through the standard again yet with an eye to precisely where else we may want to open it up, but will do so. If I take too long, consider it a vote for (2).

--Theresa Dower
 
> -----Original Message-----
> From: registry-bounces at ivoa.net [mailto:registry-bounces at ivoa.net] On Behalf
> Of Patrick Dowler
> Sent: Tuesday, July 05, 2016 12:30 PM
> To: registry at ivoa.net
> Subject: Re: VOResource 1.1: IdentifierURI
> 
> 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