MType Spectra vocabulary

[Mark Taylor]

On Thu, 8 May 2008, Mike Fitzpatrick wrote:

> In the discussions before the SAMP draft went public the idea that an MType
> like 'table.load' where the format of the table was left undefined
> clashed mightily
> with the idea that an MType should have a well-defined, unique, meaning.  I'm
> actually with Alasdair that an app should be free to accept a table.load message
> but reply with an error if it can't make sense of it, the idea being
> that an app can
> can subscribe to table.load and be expected to do something reasonable, even
> if later versions would support table.load.votable.v2 as a more specific case.
>
> For this to work, we'd need a concept in SAMP that an app subscribing to
> table.load.votable would be willing to read a table.load message as well, i.e.
> is the MType  a direct string match, do we allow wildcards like table.load.*,
> or is there an implicit subscription to higher-level messages like table.load
> if we explicitly post table.load.votable as an Mtype?
>
> I personally advocate the wildcard or super-class approach since it means
> we don't tie MTypes to a specific version of an app, we instead rely on an app
> to reject a message rather than using the Sender to find a specific match.
> This is more work for the Hub and an idea that didn't survive the draft writing,
> but I do not think the <predecessor> model of simply documenting MTypes
> in-use is viable in the long term and argues against the idea of flexibility.

More work for the hub is not a problem - wildcard matching would not be
all that difficult, and ease of hub implementation is not a high
priority in any case.

However, wildcarding MTypes is problematic for the following reason.

Presumably the point of subscribing to a wildcarded MType is so that
you can receive messages which you didn't know existed.  The trouble
with that is, if you receive a message which you've never heard of
before, you can't have looked at the documentation, so you don't know 
what the message is supposed to mean, or what the supplied parameters 
are supposed to be for, or what kind of return value you should supply.
How are you supposed to process such a message?
It is probably obvious to a human how to guess the syntax 
and semantics for a new message "spectrum.load.fitstable" if they already 
know about "spectrum.load.votable", but it is a mistake to suppose that 
you can do that sort of thing programmatically.

I can only see this working if ancestor (less specific) MTypes are 
required to specify the syntax (parameters and return value) 
and semantics of any possible descendent (more specific) ones.
While that might be workable for a parent like "table.load.*" 
(though can you come up with something which covers both 
"spectrum.load.votable" and "spectrum.load.echelle"?) it would 
be pretty hopeless for "spectrum.*" and completely hopeless for 
the top level "*".

Succinctly: the syntactic and semantic implications of extending an
MType by appending ".something" are not implicit, and it's difficult 
to know how to make them explicit.

Given this consideration, really the only kind of application that can
sensibly subscribe to wildcarded MTypes would be a logging or monitor
application, which makes no attempt at interpretation of message
semantics but just writes them to a log or displays activity in a GUI 
or something.  Even that is somewhat problematic, since it will not 
in general know what form of reply is required (though it could respond 
to all messages which require replies by signalling an error).

Incidentally there was a mechanism to subscribe to all messages in
early versions of PLASTIC, but it was effectively removed for these kinds
of reasons.

I think a much better approach to this sort of thing is to define 
named parameters for given MTypes.  So instead of:

    MType: spectrum.load
    params: url (string) - URL of the spectrum (any format) to load

    MType: spectrum.load.votable
    params: url (string) - URL of the VOTable to load as spectrum

    MType: spectrum.load.fitstable
    params: url (string) - URL of the FITS table (HDU#1) to load as a spectrum

    MType: spectrum.load.fitstable.extnum
    params: url (string) - URL of the FITS table to load as a spectrum
            extnum (SAMP int) - index of HDU in fits file containing table

we have

    MType: spectrum.load
    params: url (string) - URL of the spectrum to load
            format (string) [optional] - format of the resource at url;
                            current known values are "votable" or "fitstable"
            fitsextnum (SAMP int) [optional] - if format="fitstable",
                            the index of the HDU containing the spectrum
                            to load

Labelling and documenting different parameters in this way gives you a
much better chance of being able to work out what's meant by a message,
even if the MType has undergone extension since you read the documentation;
for instance if you come across a value of format="ascii"
you may be able fo figure out what's going on.  With the rule that
you should ignore parameters which you don't know about, it also becomes
possible to extend such MTypes in the future, for instance by adding
something like

           userlabel (string) [optional] - text string used to identify the
                           loaded spectrum to the user

though such extensions will only work if the message can be understood 
to a basic extent when the newer parameter is ignored.

This model also to some extent sidesteps uninteresting but fiddly 
questions like, should we define the MType "spectrum.load.votable.echelle" 
or "spectrum.load.echelle.votable"?

There is a downside to this, which is that if too much of the detail
is put into the parameters rather than the MType then it may not be
possible to subscribe to messages in a sufficiently fine-grained way.
I can think of some possible approaches to that, but I'll leave 
that for now.

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/