Home for the UWS Registry Extension?

[Markus Demleitner]

Hi,

[suggestion: let's continue this discussion on grid at ivoa.net; this is
going to become ugly, and as it happens, schema versioning, which is
giving a headache here, is grid territory as well]

I've had a look at the draft note, and I've made three commits that
are mainly technical in nature (rev. 5064...5066).  After reading it,
I'm pretty sure we should push it out as a note fairly soon; if we
could have it ready when TAP 1.1 goes REC, that'd be good.

TL;DR: we have a problem with XML schema versioning.

On Tue, Jun 12, 2018 at 11:21:39AM +0100, Mark Taylor wrote:
> Sec 1.1:
>    The first sentence mentions the TAP 1.1 specification,
>    but the citation is to TAP 1.0 (2010).

...which is one good reason to synchronise the note with TAP 1.1-REC.

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

That *is* confusing.  And we may want to do something about it.  Not
sure what, though.

First: According to the current Identifiers 2.0 plan, if clients
really want to discover by minor standards version (and I argue they
should not in general), they will match literally against a
standardID with a versioned tag (e.g., ivo://.../TAP#service-1.1).
That won't work when standards use old-style standardIDs -- and
frankly, I think once we actually have all these different minor
versions, I suspect we'll find Identifier 2.0's plan to have minor
versions in the identifiers was misguided as well.

Second: Well, XML versioning says that, on your "root elements" (see
below), you should have a version attribute.  That corresponds to the
full version of the *schema* -- in this case, UWSRegExt.

And here disaster strikes exactly when we have just passed the
schema versioning policies into an EN.  Here's the deal:

The idea of schema versioning is that when you pull an element (or,
in the case of VOResource, a type) from a different schema, you put,
into the outermost element coming from that other schema (the "root
element", if you will), the full version of that schema.  For
instance, a TAPRegExt 1.1 capability within a hypothetical
VODataService 1.2 record would look somewhat like this:

  <ri:Record xsi:type="vs:CatalogService" version="1.2"
      xmlns:vs="...">
    ...
    <capability xsi:type="tr:TAPCapability" version="1.1"
      xmlns:tr="...">

Again, these @version values are the versions of the *schema* file.
Note again that neither vr:Resource nor vr:Capability have version
attributes; these are added by the vs and tr schemas following the
plan of the schema versioning EN.

Distaster strikes with interface.  vr:Interface already has an
@version attribute.  So, it's not available for schema versioning
use.  Worse, it means something fundamentally different: it's the
version of the thing described (the interface) rather than the
version of the thing describing (the schema underlying the XML
resource record).

Oh bother.

If someone has a good idea how to clean this up, please speak up.
Right now I'm suffering from a broken collarbone, which is my perfect
excuse.

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

As long as we have not identified strong use cases to discover by
minor version, my take would be: interfaces declare the highest
version they implement.  That would cover the "I need some extra
feature only available since version 1.2" use case, which currently
is the only discovery use case I find somewhat credible.

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

While I agree that swallowing DALI-sync into UWS is not a good idea
(in particular because DALI already references UWS for its async),
I'd not worry too much about this detail at this point.

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

That was a typo.  I've already fixed it in rev. 5066.

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

Arguably.  +1 from me, unless there's a strong case not to.

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

Right.  My gut feeling would be to actually pull the schema from

http://www.ivoa.net/xml/VOResource

-- this will always be the latest 1.x schema, and that means that
UWSRegExt (assuming it will have a longer life and not be absorbed
into VODataService) will profit from any maintenance on VOResource we
will do.

The disadvantage, of course, is that UWSRegExt will profit from any
maintenance on VOResource -- i.e., it will change without the spec
changing.

By XML versioning, these changes have to be compatible, though.  So,
I'd argue less things should break if we pull schemas by major than
by minor version.

Which is another thing we should discuss in the schema versioning EN.
I think it's time to start SchemaVersioning-1_0-Next...

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

We need implementations and use cases.  Anyone planning to require
authentication -- could you perhaps run and register a pathfinder
service as soon as possible?  We *really* need something to play with
before we can confidently say what'll work and what not.

        -- Markus