VOResource 1.1: Mirrors?

[Markus Demleitner]

Dear collagues,

On Tue, Jun 14, 2016 at 11:25:03AM +0100, Mark Taylor wrote:
> On Tue, 14 Jun 2016, Markus Demleitner wrote:
> 
> > I took away from our mirrors discussion that
> > 
> > (a) people want the concept of mirrors in the registry,
> > 
> > (b) modelling each mirror as a separate resource is not appropriate
> > for all the cases (in particular not for VizieR)
> > 
> > (c) there is no obvious candidate for metadata beyond the plain URL
> > of the mirror.
> 
> Sorry I haven't engaged with this so far, but briefly: addition
> of mirrorURL sounds OK, it's probably an improvement on not
> having them.  However, presented with a bag of apparently
> undifferentiated mirrors, it's hard to imagine how a
> non-non-sophisticated client is going to make an intelligent
> choice between them, unless it already has out-of-registry
> information about the service.
> 
> The obvious thing is to present the list to the user and get them
> to decide.  Thinking about the UI for that, some terse human-readable
> information would be useful, e.g.:
> 
>    <accessURL use="base">http://example.edu/svc/stars?</accessURL>
>    <mirrorURL use="base" description="Primary backup" >http://example2.edu/svc/stars?</accessURL>

The usage scenario sounds very reasonable, so I'd say let's do it.
I'm not 100% happy with "description", as that, at least in other
contexts, implies something that can be longish.  I went for @title
now.  Also, pushing something like this into an attribute feels a bit
wrong in VOResource, which tends to have elements rather than
attributes.  But I certainly don't want to have mixed content, so
attribute it is.  (Volute rev. 3454)

But, just because I see it here: Note that mirrorURLs do not have
@use (or, indeed, any other metadata accessURL might grow).  This is
supposed to be used for strict mirrors only, i.e., you can expect
identical behaviour from all URLs given; so, mirrorURL does indeed
normalise the model a bit.

>    <mirrorURL use="base"
>               description="Primary backup"
>               mirrortype="ivo://ivoa.net/std/VOMirror#backup1"
>               >http://example2.edu/svc/stars?</accessURL>

For something machine-readable we've seen Mark's @mirrortype and
Pat's "ordering" of some sort.   At this point I agree with both of
them: Let's not go there before we actually have a clear problem to
solve *and* implementation experience.  So, I'd not stick anything
else into mirrorURL for now.

> > I feel a bit bad for doing this, as I don't see that any software
> > might use this by the time I'd like VOResource 1.1 go to REC, and
> > nothing to go to REC that's not been tested in use.  So, if a client
> > author volunteers, I'd be happy to work with you.
> 
> I'm not promising, but: before clients can use it, there would
> need to be some of this content in the registry to test it on.
> Is that likely on the time scale you've got in mind, and if so for
> what types of service?

Well, we're back in the chicken-and-egg situation that prototyping
will make your (registry) service formally invalid, and without
prototyping, something should not become a standard, but: perhaps we
can just try this with a few records -- would anyone operating
mirrors of something TOPCAT-queriable be in on that? [if all else
fails, the reg.g-vo.org mirrors might work, but I'd rather have
something DALier...]

Cheers,

          Markus