SimpleDALRegExt 1.1 WD

Markus Demleitner msdemlei at ari.uni-heidelberg.de
Mon Jun 13 14:26:03 CEST 2016


Hi Mark,

Thanks for your feedback.

On Mon, Jun 13, 2016 at 10:58:10AM +0100, Mark Taylor wrote:
> Markus,
> 
> On Tue, 7 Jun 2016, Markus Demleitner wrote:
> 
> > Dear Registry,
> > 
> > I completely forgot to announce here the availability of the
> > SimpleDALRegExt 1.1 working draft at
> > 
> > http://ivoa.net/documents/SimpleDALRegExt/20160525/
> > 
> 
> Abstract:
>    "... the four fundamental data access protocols - SCS, SIA, SSA, SLA"
>    I'm not sure that fundamental is the best way to describe them,
>    especially post-TAP.  Replace "fundamental" by "simple" or
>    "first generation"?  Or just use the list of names without further
>    editorialising?

I think the accepted technical term is "typed", and hence I've made
this:

   This specification describes how to describe a service that
   supports any of the four typed data access protocols -- Simple
   Cone Search (SCS), Simple Image Access (SIA), Simple Spectral
   Access (SSA), Simple Line Access (SLA) -- using the VOResource XML
   encoding standard.

Better?  I'm not objecting to

   This specification describes how to describe a service that
   supports any of the Simple Cone Search (SCS), Simple Image Access
   (SIA), Simple Spectral Access (SSA), or Simple Line Access (SLA)
   protocols using the VOResource XML encoding standard.

or something similar, it just sounded a bit odd to me.  If you like
some sanitised form of this better, by all means change the document.

> Sec 2:
>    The Note about how "many clients discover the standard endpoints..."
>    is useful.  Could it be accompanied by a note or discussion about
>    what the recommended way to do that is?

I'm not so wild about codifying this in too many standards; I'd
probably prefer to have even less of this in here.  SimpleDALRegExt
isn't an ideal place since hopefully there's a uniform way to
discover "standard" services, so SimpleDALRegExt would have material
ruling into its "siblings" (TAPRegExt, VOEventRegExt (hint, hint),
etc.).  

I'm trying to have the "official" recipe in VOResource 1.1, whereas
the "practical" aspect is currently given by
http://ivoa.net/documents/RegTAP/20141208/REC-RegTAP-1.0.html#tth_sEc10.1
and the introductory text to that chapter musing about intf_role
(which we'll hopefully repair in VOResource 1.1, too).

Hence, I'm not wild about having another spot we might forget when we
update the actual procedure.

> Sec 3.3.6:
>    This section declares itself to be a temporary measure for services
>    deployed prior to the SSA Recommendation (presumably SSA 1.03,
>    Dec 2007?).  Should it be retired or deprecated now?

I thought there were still quite a few services around using this,
but

select ivoid from rr.capability where cap_type='ssap:protospectralaccess'

shows there's just one serivce left in the Registry.  So, I've taken
the liberty of purging the text of references to it ("damnatio
memoriae") and replacing the section content with

  The \xmlel{ssap:ProtoSpectralAccess} type still defined in the schema
  was inteded for seamless migration of services predating the SSAP
  specification.  It should no longer be used.

Objections, anyone?

> Also, there are some funny quote characters (U+201E?) in the LaTeX
> source:
> 
>    % grep indicating.the.largest SimpleDALRegExt.tex
>                           is ???Cutout??? or ???Mosaic???, indicating the largest 
>                           is ???Cutout??? or ???Mosaic???, indicating the largest 
> is there any reason?

These are "proper" UTF-8 opening and closing quotes (`` in '' in TeX)
pulled in from the schema.  I didn't want to have TeX quotes in
XML schema, and I didn't want the "machine" quotes in the typeset
document, and I didn't want to have to guess opening and closing
quotes in the documentation generator, and hence ended up using the
UTF-8 quotes.

But of course you're right, I should have used English (rather than
German, as in SIA-v1.2.xsd) opening quotes.  Which is now fixed.

Thanks,

             Markus


More information about the registry mailing list