Home for the UWS Registry Extension?
Brian Major
major.brian at gmail.com
Fri Mar 2 20:18:20 CET 2018
Hi Markus,
On Mon, Feb 26, 2018 at 1:20 AM, Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:
> Hi Brian,
>
> On Thu, Feb 22, 2018 at 04:58:16PM -0800, Brian Major wrote:
> > Hi Grid, Registry,
> >
> > At the Santiago Interop we decided to identify the sync and async
> endpoints
> > of a TAP 1.1 capability by setting the 'type' of the Interface element as
> > one of either
> >
> > uws:Sync or
> > uws:Async
> >
> > instead directly in the standardID of the capability like
> >
> > ivo://ivoa.net/std/tap#sync-1.1 and
> > ivo://ivoa.net/std/tap#async-1.1
> >
> > We have implemented this in our TAP (1.1) services using the XSD here:
> >
> >
> > https://github.com/opencadc/reg/blob/master/cadc-registry/
> src/main/resources/UWSRegExt-v0.1.xsd
> >
> > And it is all working as expected, no issues.
> >
> > Now I am wondering now where this XSD can be placed within the IVOA and
> how
> > it can be documented to describe the intended use. This will need to go
> > somewhere official ahead of TAP 1.1. Any suggestions are welcome.
>
> While it is of course possible to just go ahead and specify this in
> UWS 1.2, thus creating a new "official" IVOA schema, in the interest
> of keeping the total number of schema files people need to deal with
> (and also because at least sync arguably isn't really related to
> UWS), I'd actually prefer to have these types in VODataService 1.2,
> where there's already stuff like ParamHTTP, which in some sense is a
> sibling of your uws:Sync.
>
Well, I think it is certainly UWS related, but I agree that a UWS 1.2 is
too much.
>
> Work on VODataService 1.2 has started with
> http://ivoa.net/documents/Notes/Regstc, which already has a draft
> schema with some updates.
>
I'd say that adding it to VODataService is also too heavyweight for a
number of reasons. The extension may change to have content (rather than
just acting as a 'tag') in the near future. Having it described in this
upstream spec would make it that much harder to change. I'm in favour of
keeping it close it's source. That is, in GWS and associated with UWS.
So, how about a short UWS Registry Extension note so we can get it approved
relatively quickly ahead of TAP 1.1? I'd be willing to write that up.
Also, what about the version of the extension? We currently have it at 0.1.
>
> So, here's what I can offer if people agree these two types should be
> added as part of VODataService 1.2 (rather than a separate standard
> or UWS 1.2): Create a repo for VODataService 1.2 in volute and put
> the new features from Reg-STC and your UWS work into the schema.
>
> That could happen within two weeks, say. After that, we could work
> out some way to have the schema file as a beta in the schema repo and
> (I've been lobbying for that already) possibly even in the RofR
> validator.
>
> Sure, it'll be more than a year until the thing reaches
> recommendation status -- but frankly, I guess any other way to make
> these things official won't be much quicker...
>
> -- Markus
>
Cheers,
Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20180302/fe1f480b/attachment.html>
More information about the registry
mailing list