Working Draft - Simple Cone Search, v.1.1 2020-08-28 - released

[Markus Demleitner]

Hi Theresa,

On Tue, Sep 01, 2020 at 02:18:50PM +0000, Theresa Dower wrote:
> From the Registry end: it seems it may be helpful to add
> capability/interface information noting time information support,
> especially in the test query. Note this change would be in
> SimpleDALRegExt, and included back to the main CS document.  Do we
> think this section is solid enough to work on it now, or do we keep
> it in mind for later in the WD process?

I'm fairly convinced we should phase out SimpleDALRegExt as the
standards covered there get reviewed -- discovery is an integral part
of a standard and thus shouldn't be regulated somehwere else.
That we did it differently for the old S-protocols was just because
the Registry wasn't (really) ready when the SCS and SIAP came along
(well... for SSAP and SLAP Registry would have been there, but the
bad pattern had already been established).

So... I'm rather fervently for retiring the SCS section in
SimpleDALRegExt and having everything in SCS.

[Apologies to DAL: Registry in-talk start]
Now that I skim SimpleDALRegExt again I notice it doesn't say "only
valid until overridden" clearly and early enough.  While it's still
in WD (pending a few more adoptions of SSAP productType), I think I'd
just explicitly say:

  Regulations here are only valid until the specifications themselves
  define their modes of discovery.

in the abstract and repeat it a few times at strategic places in the
document.
[Registry in-talk end]


As to noting TIME support: Well, we already have param in
vs:ParamHTTP (DaCHS, for instance, has declared its SCS parameters in
this way forever).  Sure, you need to query the Registry to figure
out parameters in this way, but while doing discovery that's not a
problem.

When talking to a service a client has run into in another way, I'd
say MAXREC=0 metadata discovery, SSAP-style, ought to do the trick.

        -- Markus