SSA-1.1

Markus Demleitner msdemlei at ari.uni-heidelberg.de
Wed Apr 27 07:49:28 PDT 2011


On Wed, Apr 27, 2011 at 06:12:25AM -0700, Rob Seaman wrote:
> There seems to be some notion here of setting a broad precedent for
> IVOA interfaces.  As Myron says, it surely will be significant for
> numerous use cases to preserve both case and whitespace.  Can't

Plus, there's the issue of metacharacter escaping (at least the
asterisk is part of various identifiers).  Do we really want
backslash escaping in TARGETNAME?

First, for the current SSA draft: If anything needs to be said at all
then it should be a clarification as to matching modes for
TARGETNAME.  IMHO that should be: "There are no metacharacters in
TARGETNAME. Clients should not assume any case folding or
whitespace normalization on the server side.  Servers are free to
perform case folding and/or whitespace normalization."

I can, however, very well see a strong need for lenient matching.
The clean way to add this would be to add another SSA parameter, say,
TARGETRE, that takes an RE of some sort.  I guess * and ? as
wildcards are the minimum, plus, in consequence \*, \?, and \\ to
match the metacharacters literally.

I'm not so sure whether we should prescribe case folding, and even
less sure if we should require whitespace to be ignored in TARGETRE I
suspect it would help users a great deal given what we find in FITS
headers, though.  

If we wanted to let people toggle the respective behaviour, I *could*
imagine things like \c and, say, \s, like in vi(m) (where \c turns on
case insenstive matches, \s would then turn on whitespace ignoring).
But that's really starting to get ugly.

Whatever it's going to be, it's something for the next major SSA version
(though, with sufficient consensus, we might sneak in some language
"in the next version,..." in the current draft, eh?)

For the record (and maybe the next major version), I believe
TARGETNAME queries could immediately be made much more useful if
services had a standard way of exposing a list of names they have
data for.  For most SSAP servers that should be something readily
transferable (i.e., maybe some 1e3 names).  So: I'd like to see a
REQUEST=getTargetNames operation, returning a one-column VOTable, or
at least one that has a column with a meta.id;meta.main UCD or
somesuch.


Cheers,

       Markus



More information about the dal mailing list