Home for the UWS Registry Extension?

[Mark Taylor]

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).

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.  That also raises the question
       of having multiple interfaces with the same securityMethod
       and xsi:type, but different versions.

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 ...".

   "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?


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?

   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".

   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>).

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"


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/