VOResource 1.1: IdentifierURI

[Markus Demleitner]

Hi,

On Wed, Jul 06, 2016 at 01:47:40PM +0000, Theresa Dower wrote:
> I definitely agree in the case of standardID, and, like Pat,
[on having it xs:anyURI]

> 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).
> > From: Patrick Dowler
> > Sent: Tuesday, July 05, 2016 12:30 PM
> > 
> > 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.

Ok.  If Pat and Theresa feel that standardIDs should be xs:anyURI,
the case for having a general identifier pattern (with "local parts")
becomes very thin indeed.  Which means I'd retract my preference for
(2) -- generalise IdentifierURI, introduce RegistryReference -- and
would now go for:

IdentifierURI stays what is is, but there's a change in documentation
that makes it clear that it is *only* to be used if it's semantically
clear that what's referenced is a registry record.  From the usage in
VOResource and friends, that's true for

vr:ResourceName/@ivo-id
vs:ServiceReference/@ivo-id (which is for footprint, and I'm really
  not sure whether I expect separately registred footprint services,
  but that's a different issue)
vr:Resource/identifier
vg:Resources/identifier (which is part of the RI1.0 search interface
  and thus is a zombie anyway)

The following would be switched to xs:anyURI:

vr:Validation/@validatedBy (or is this actually intended to resolve?)
vr:Capability/@standardID

If nobody protests, I'll do that on Monday.

Cheers,

          Markus