Problems with the SSA XML Schema - SSACapRestriction

[Markus Demleitner]

Hi James,

On Fri, Jul 17, 2020 at 07:41:51AM +0000, Dempsey, James (IM&T, Black Mountain) wrote:
> I am not sure if registry is the right place for this question, so
> my apologies if it is not!

Is is -- while in the future I'd like to have these Registry
extension schemes in the documents that define the standards, in this
case it's (still) SimpleDALRegExt, maintained by Registry.

> I've just tried updating the registry entry for our SSAP service.
> However the document validation fails with the following error:
> 
> Server Error: Invalid update, document not valid The document is invalid with respect to its schema
> src-resolve: Cannot resolve the name 'ssap:SSACapRestriction' to a(n) 'type definition' component. Found at line 958, column 54 in http://www.ivoa.net/xml/SSA/v1.1

Oh wow.  How did that go unnoticed for so long?

So, here's the story: Way back when SSA was prototyped, some early
services used an extension type called ProtoSpectralAccess, and when
SimpleDALRegExt became REC, this type was left in in order to not
make these early registrations invalid in one go.  Indeed, only late
last year I stomped out the last ProtoSpectralAccesses so the thing
finally goes from the SSA schema with version 1.2, due for RFC when
there's a bit more takeup (the thing was briefly mentionend in my
Groningen update,
https://wiki.ivoa.net/internal/IVOA/InterOpOct2019Reg/sdre.pdf).

Anyway, when I uncoupled standardID from the SimpleDALRegExt types in
the run-up to version 1.1 (if you're curious, rev 3256 in Volute,
https://volute.g-vo.org/svn/trunk/projects/registry/SimpleDALRegExt),
I either forgot about loosening things up for ProtoSpectralAccess, or
I figured it would die soon anyway.  The net effect was that
ssap:SimpleSpectralAccess was based on vr:Capability as expected,
wheras ssap:ProtoSpectralAccess still used the then-vanished abstract
type ssap:SSACapRestriction (which used to fix the standardID).

This poses the question of why nobody noticed this breakage before.
Looking at DaCHS, I notice that I went directly from SSA-v1.1 to a
prototype SSA-v1.3 that already didn't have ProtoSpectralAccess any
more; that late takeup, in turn, wasn't noticed because I (and
probably nobody else) had SSA auxiliary capabilities; all there were
were SIAP and TAP auxiliary capabilities.

Morale: If it's not implemented, it's probably broken.  And: Every
feature, even when introduced for backwards compatibility, has a
maintenance cost.  Let's have as few of those as we can.

How do we fix this?  Well, since this is about a type that'll be gone
in SDRE 1.2 anyway, I'd say we make a silent update to the v1.2
schema (that came with SDRE 1.1); does anyone insist on an Erratum?
Me, I'd say the intention or the original standard is very clear.

I'll still fork off volute rev. 4109 (which is what was released as
REC-1.1) to branches/simpledalregext-1.2-fix so there's some record
of this.  And I'll link to this thread.  The SSA-v1.2.xsd in there
I'll re-submit to Giulia.

Or would anyone like a more formal proceedings (in which case it'd be
nice if they'd support me in them).

         -- Markus