new take on resource registration best practice

[Ray Plante]

On Wed, 23 Oct 2013, Markus Demleitner wrote:
> There's a catch, however: ...
> ... would hit the
> service containing that capabilitiy fairly often.
> 
> Therefore, I'd say these "served-by" capabilities should have special
> standardIds (maybe just the normal standard ids with "?service-for"
> appended?).

Thank you for reminding us--we did talk about this as a way to 
distinguish them.  I like this idea.  Like you explained, it's low 
impact.

> This wouldn't necessarily require VOResource changes.  What
> would, AFAICS, require those would be the declaration of the ivoid of
> the "donor service", i.e., the one that embeds the "real" capability.
> If we're *really* afraid of schema changes, we can simply require
> that ivoid be given in a relation element.  don't like that much.
> I'd much rather have some way to say that in the capability itself --
> it's far less brittle and easier  to deal with, in particular with
> interfaces returning actual VOResource XML.


> On Wed, Oct 23, 2013 at 01:46:26PM +0200, Pierre Le Sidaner wrote:
> > I just want us to separate two point :
> > The way we want the services and collection to be registered by the
> > users. (example for registering one tap with multiple collections)
> > The way we want to ingest them in the registry. (or the way we would
> > like to retrieve informations)

...

> But if we can avoid this, we should.

I tend to agree when we are talking about best practices/conventions; 
it makes things simple to explain.  As I said before, I don't mind 
this as an "extra smarts" a registry applies when it recognizes 
separate collection-vs-service resources.

cheers,
Ray