Apps Messaging - mtypes

[Mark Taylor]

Mike,

On 4/6/07, Mike Fitzpatrick <fitz at tucana.tuc.noao.edu> wrote:

>      More specifically, a MESSAGE contains an 'mtype' attribute that
> defines the semantic meaning of the message.  The concept behind the
> 'mtype' (described in more detail below) is based loosely on the use of
> UCDs in that a (small) controlled vocabulary is sufficient to describe the
> majority of concepts needed in applications messaging.  The mtype is made
> up of 'atoms' to construct 'words' that are not only meaningful to the
> developer, but allow applications to easily match regular expressions by
> using wildcard characters to filter messages that may or may not match a
> specific capability in the application.  For example,  an mtype expression
> of "display.*" might imply some sort of image display capability where
> 'display.URL' means an app can specifically download/display and image
> from
> a URL.  A task may wish to connect by advertising interest in the more
> general display messages, but is free to reject specific messages it
> cannot
> handle.

I agree that the existing URI-like PLASTIC 'message IDs' are rather 
an ugly lot - as John says they are intended as opaque strings, 
with uniqueness guaranteed by their hierarchical nature, 
and the semantics is in principle documented somewhere-or-other, 
though we've not been very well-organised at doing that. 
They are ad-hoc by design in that each message is defined as it's 
required, usually following some discussion on the mailing list 
about its form (argument list and semantics).  They are then 
(in principle) recorded and documented in a public place.

I think that rationalising the naming along the lines that you suggest
may be a good idea, but I'm not necessarily in favour of attempting
to come up with names which are supposed to be machine-parsable.
I understand the concept of claiming to support "display.*"-type
messages, but I'm not sure under what circumstances such a claim
would be useful.  If an application can display FITS, GIF and JPEG 
images but not other types I don't see that either the receiver or the
sender benefits from the receiver advertising that it potentially 
supports display of any kind of image.  Do you have a use case
illustrating the advantages of parsability of mtypes?

Outlining one of the core PLASTIC use cases may be useful here;
interestingly this isn't one that we considered up front, but it's 
the one which has emerged as the most common one.

   1. An application X identifies the URL of a VOTable from somewhere
      (e.g. cone search).  It knows that it is a VOTable.
      It wishes to provide the facility for passing this to some other
      software component, which may be able to do something interesting
      with VOTables.

   2. X finds out from the hub which other currently-running
      applications can do something useful with a VOTable, and provides
      a list of these to the user (e.g. a popup menu).  Some of the
      applications which declare their ability to deal with this
      kind of data may provide additional human-readable information
      about what they will do with them, and/or provide multiple
      options in this regard.  So for instance A's "do something with
      this VOTable" menu might look like:

          Aladin: load
          TOPCAT: load
          Y: crossmatch
          Y: convertToFITS

   3. The user may select one or more of these applications and
      initiate sending the message thus specified.

In this case it's important, as far as possible, that each of the 
options presented to the user actually does something, i.e. that
applications advertise their capabilities accurately rather than
claiming they support messages (such as display.*) which in practice 
they will treat as a no-op.

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/