WD-AccessData-1.0-20140312

[Markus Demleitner]

Hi Pat, Hi DAL,

On Mon, Mar 17, 2014 at 11:34:30AM -0700, Patrick Dowler wrote:
> 
> Comments in-line:
> 
> 
> On 17/03/14 01:50 AM, Markus Demleitner wrote:
> >On AccessData in principle -- is there anything that can be done
> >with the current, 18-page draft with lots of complex syntax and many,
> >many open questions that could not be done with the simple annex to
> 
> OK, that's the first time  heard an 18-page IVOA spec called complex :-)

Well, count the number of grammars implicit in the spec.  And both
the implicitness and the number of them cause complexity.

> ><PARAM name="BAND" datatype="char" arraysize="*" unit="m">
> >   <VALUES><MIN value="3e-7"/><MAX value="5e-7"/>
> >     <OPTION value="V"/><OPTION value="B"/>
> ></PARAM> ?
> >
> Yes, that is pretty horrible and I don't know why you would think
> anyone is proposing that. There is absolutely no intent to mix
> numeric wavelength values with strings like B and V.

Phheewwy.

> something else. If we want to reserve BAND for known energy band
> names or somesuch simlair usage then we could do that. LAMBDA would
> not be my first choice for a numeric energy parameter for a variety
> of reasons:
> 
> - looks optical-centric and radio and high energy people scoff and go away
> - in future, when we go on to allow some use of native coordinates
> that will look like a colossal amount of short-sighteness

Well, a protocol is a contract between a client and a server.  The
protocol works better the tighter that contract constrains mutual
behaviour.  This means we have to make choices such as "spectral
range is specified as wavelength in meter" (which is not terribly
optical-centered).  Energy in eV or frequency in Hz would do as well,
but it has to be a single thing, or clients will have a very hard
time exposing sensible interfaces to collections of services.

With the parameter triples, specific communities would still be free
to define (hopefully in addition) their own ways to express this, but
frankly I don't think that's going to be a big issue because this is
a protocol and *not* a user interface (see below).

> >The good news is that something like this can easily be pulled off
> >sanity-preservingly:
> >
> ><PARAM name="LAMBDA" datatype="double" unit="m" ucd="em.wl">
> >   <VALUES><MIN value="3e-7"/><MAX value="5e-7"/>
> ></PARAM>
> ><PARAM name="LAMBDA_WIDTH" datatype="double"...>
> 
> All this does is use two parameters to perform a search when a single
> parameter with a value range will do. This just isn't in line with
> what did work from what we did before and with the trend in how apps

That's my point: It did *not* work.  You cannot reliably do
non-trivial cross-service SSAP queries exactly because the
alphabet soup going in is under-specified and the metadata returned
by the services insufficient.  It's not even a problem of invalid
services: It's a problem of validatiability  And the whole reason I
keep howling here is that I want to keep that from happening again.

So, yes, I am suggesting a break with previous practices, and yes, I
hugely prefer two well-described parameters to one murky alphabet
soup.

> tend to work. And it is just not what users ask for, if I can judge
> by what the astronomers that use our apps ask for... they want fewer
> boxes/params with a bit more power in them. That is what ranges (and
> geometry in POS) gives them and they can use them effectively.

This is a *protocol*.  Users shouldn't see any of this, unless
they're advanced enough to be able to write their own user
interfaces.  So: please let's not build our preconceptions of
suitable UIs into the protocol and instead make the protocol
UI-agnostic: The protocol should be rich enough to not constrain
presentation.

Again, in order for clients to be able to sensibly expose user
interfaces designed to fit their user's requirements, they must
understand the parameter set of the servers they are talking to as
well as possible (example: specify a spectral cutout using a slider
with two tabs measuring in GeV.  Or via a magic-eye type control.  Or
via the scrollwheel on your mouse.  Or using eye tracking.)

Good and complete parameter metadata is there *exactly* to allow
decoupling UI from protocol.  Atomic parameters are there in order to
avoid prejudicing UIs and to enable discipline specific UIs.

> Why not
> 
> <PARAM name="LAMBDA" datatype="double" unit="m" ucd="em.wl"
>        xtype="dal:range">
>     <VALUES><MIN value="3e-7"/><MAX value="5e-7"/>
> </PARAM>
> 
> OK, I just pulled "dal:range" out of thin air and I'm probably
> abusing something horribly... but we have long used range-valued
> params so we need to be able to describe them. The way to describe
> them should go in DataLink, in the service descriptor section. So,
> how to describe them?

This is a possibility, and if we're actually doomed to keep the
alphabet soups although they've been shown to be a serious liability,
we'll have to do something like this.  It'd still be a pain.  Try
this for POS, for starters.  And doesn't it strike you as odd that we
ask clients to accept 2.3/3.4 for a VOTable double if we do this?

Again: Why all the effort to save a known-brok^W^W^W practice that
has been shown to have issues when there's an easy, elegant, and
proven way out?

Incidentally, I'm all for modelling ranges and such explicitly --
there's data models implicit in much of this, and advanced clients
that want to deal well with custom extensions will need (or at least
want) them in an explicit form.  The good news is: With atomic
parameters and VO-DML, we can get the standard out of the door
quickly before we have figured all of that out, and later provide
rich and complete annotation of advanced use cases.

Cheers,

         Markus