Home for the UWS Registry Extension?

[Brian Major]

Hi Mark,

Thanks for the review and comments.

On Tue, Jun 12, 2018 at 3:21 AM Mark Taylor <m.b.taylor at bristol.ac.uk>
wrote:

> Brian,
>
> some comments as requested on the content of the UWSRegExt draft:
>
> Sec 1.1:
>    The first sentence mentions the TAP 1.1 specification,
>    but the citation is to TAP 1.0 (2010).
>

It now cites the 1.1 PR, thanks.


>
> Sec 2.2:
>    "Clients can recognize the TAP service as version 1.1 by checking
>     for a version attribute with the value "1.1" in the capability."
>
>        This is either confused or confusing (or I am): as far as
>        I can see the <capability> element does not have a
>        version attribute.  Clients have to look for version="1.1"
>        in (a? the?) <interface> element within the target capability.
>        So the TAP (or whatever) service itself is not versioned,
>        its various interfaces are.


Okay, I've corrected that and made it clear that the version attribute
appears in the interface not the capability.


> That also raises the question
>        of having multiple interfaces with the same securityMethod
>        and xsi:type, but different versions.
>

When another TAP version comes in the future (say 1.2) I think that such a
circumstance would be an acceptable way of distinguishing between 1.1 and
1.2, no?


>
> Sec 3:
>    "... how the various UWS endpoints (namely the synchronous and
>     asynchronous job execution endpoints) are to be discovered..."
>
>       To me the synchronous endpoint is not a UWS endpoint at all.
>       I would just write something like "... how the synchronous
>       and asynchronous endpoints are to be discovered ...".
>

Okay, I agree, that sounds better.  Done.


>
>    "The surrounding capability element should be marked with the
>     minor version of service specification, as per the recommendations
>     in the XML schema versioning note ((?)))."
>
>       This looks like the same issue as noted above:
>       <capability> does not have a version attribute.
>       Does it need to grow one?  Or do you mean the standardID
>       should have a value which includes the standard's version?
>

This should also have said 'interface' instead of 'capability'.  Thanks,
fixed.


>
> Sec 3.1 example capability document:
>    The stanza following the comment "# TAP 1.0 support" is a <capability>
>    element inside a <capability> element.   I don't think that's legal -
>    should those two <interface> elements be present here on their own?
>

Hmm, I don't see that in the version I'm editing.  Perhaps it was fixed by
someone else?


>
>    The accessURL for the authenticated (tls-with-certificate)
>    TAP 1.0 interface is the same as for the unauthenticated one,
>    accessURL="http://example.com/tap".  I think it should be
>    accessURL="https://example.com/tap".
>

Yes, thanks, fixed.


>
>    The stanza following the comment "# TAP 1.1 support" contains
>    several <interface> elements with identical namespace declaration
>    attributes xmlns:uws="http://www.ivoa.net/xml/UWSRegExt/v1.0".
>    This XML would (IMHO) be more readable if the that namespace
>    attribute were factored out to an outer element
>    (e.g. the top-level <capability>).
>

I agree about the readability but, since the new 'type' values are an
extension of 'Interface' in the XSD, doesn't that break the rules?  Anyone
know?


>
> Sec 3.2 XSD:
>    This schema references VOResource-1.0 - since VOResource 1.1 is
>    now REC, should it reference that?  Given the XSD Versioning Note,
>    I *think* the only change required is to the
>    xs:import/@schemaLocation attribute that should read
>       "http://www.ivoa.net/xml/VOResource/VOResource-v1.1.xsd"
>    rather than
>       "http://www.ivoa.net/xml/VOResource/VOResource-v1.0.xsd"
>
>
Good point.  Yes, I think you're right that the only change is to the
schemaLocation (Though I don't think this is because of the XSD versioning
note, but because the namespace only serves as a label for the schema
location.  I've made that change as you recommend because it seems like it
is at least in the same spirit as the schema versioning note.).  I will
change our implementation and test to make sure.

I've uploaded this latest version to the GWS main page:

    http://wiki.ivoa.net/internal/IVOA/IvoaGridAndWebServices/UWSRegExt.pdf

Cheers,
Brian


>
> I still have my doubts about whether this approach is a complete
> or optimal solution to the problem of TAP services with multiple
> security methods, but this may not be the best place to air
> those concerns.
>
> Mark
>
>
> On Wed, 30 May 2018, Brian Major wrote:
>
> > Hi DAL, Registry and Grid,
> >
> > Sorry for the wide distribution but this touches all three working
> groups.
> >
> > An initial note for the UWS Registry Extension has been written and can
> be
> > viewed here:
> >
> >
> http://wiki.ivoa.net/internal/IVOA/IvoaGridAndWebServices/UWSRegExt.pdf
> >
> > It is very simple: the essence of the note is to allow registry interface
> > entries to 'tag' interfaces as being UWS synchronous or asynchronous
> > endpoints.  This is to allow implementers of UWS services (TAP is the
> > working example) the freedom of having separate URLs for interfaces with
> > various security methods (supported authentication) and to have custom
> URLs
> > for sync and async endpoints.
> >
> > Comments are welcome.  There is still uncertainty about how the
> information
> > in this note should be brought in as a document for reference by TAP 1.1,
> > so comments on that are welcome too.
> >
> > Brian
> >
> >
> > On Thu, Feb 22, 2018 at 4:58 PM Brian Major <major.brian at gmail.com>
> 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.
> > >
> > > Thanks,
> > > Brian
> > >
> > >
> > >
> > >
> >
>
> --
> Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
> m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20180801/d6ec26c9/attachment.html>