On Wed, 19 Jul 2006, Norman Gray wrote:

> Mark,
> 
> On 2006 Jul 19 , at 16.26, Mark Taylor wrote:
> 
> > On Wed, 19 Jul 2006, Norman Gray wrote:
> >
> >>> An alternative would
> >>> be to introduce a new message with the semantics "here is a table
> >>> containing polarimetry data - do something with it if you want".
> >>
> >> I haven't kept up with PLASTIC, so I'm not really qualified to
> >> comment on its aesthetics, but... ugh!  Isn't that legitimising all
> >> sorts of nasty namespace-pollution?
> >
> > I don't see where namespace pollution comes in.
> 
> Just in the sense that loadPolarimetryDataFromURL suggests  
> loadRadioDataFromURL, loadMillimetreDataFromURL,  
> loadMyFunkyPolarimeterDataFromURL, and a host of other things. While  
> `namespace pollution' might be the wrong term, the plurality of  
> possible messages, and the resulting expansion of the API would seem  
> to be making things harder for application authors, rather than easier.
> 
> Peter suggested `mime-types' annotating the method call.  There you  
> have the (simple, generic) verb separated from the type of data being  
> operated on.  Very O-O, or Perlish, and robust.  The only problem is  
> that you'd have to agree on `mime-types' (and standardise them via  
> Strasbourg?).

I'll sidestep the rest of this debate by quoting a post which has 
just appeared on the plastic-devs list from John Taylor:

   Date: Thu, 20 Jul 2006 00:55:27 +0100
   From: John Taylor <[log in to unmask]>
   To: B Walshe <[log in to unmask]>, Bob Mann <[log in to unmask]>
   Cc: [log in to unmask]
   Subject: Re: [Plastic-devs] Select or show colums message

   Thinking again about this, I have an idea that might allow us to combine 
   the increased "pluggability" of having a generic message with the 
   control implied by a more specific one and thus keep both you and 
   Richard happy.

   If we think of a generic selectCols(id, cols[]) message as just implying 
   "here are a bunch of columns, do with them what you will", then we need 
   a way of the recipient stating what it is able to do with the message, 
   and the sender choosing amongst the options.   We could do this by 
   decorating the message with the extra information.   URI fragments are a 
   natural way to do this, since (IIRC) the fragment is intended to be 
   interpreted by the client (the recipient of the message in this case).

   To take a specific example.  Topcat could do one of two things with a 
   bunch of columns: create a new subset based on them, or create a plot 
   (2D or 3D depending on the number of columns).
   It would register as understanding
   ivo://votech.org/votable/selectCols#plot
   ivo://votech.org/votable/selectCols#new_subset

   The fragment string is completely defined by Topcat - no other agreement 
   is needed with any other application, and no other application needs to 
   understand what it means.  Instead, the sending application (e.g. Weka) 
   strips off the fragments and uses them to populate its UI.  Thus it 
   might offer the user the following options for the selected columns:
      send cols -> topcat -> plot
                          -> new_subset
                  -> tabview-> highlight
                  -> Anomaly Detector

   [assuming tabview has registered with selectCols#highlight, and Anomaly 
   Detector has registered just with selectCols]
   The appropriate fragment is then tacked on to any sent messages.

   If Topcat should receive a message without a fragment then it could a) 
   ignore it (not so good for backwards compatibility) b) do some default 
   behaviour c) prompt the user

   The nice thing about this is that behaviour is extendible without 
   further agreement amongst application vendors.  Should astronomers ask 
   Mark to offer the ability to differentiate between overwriting an 
   existing plot, or creating a new one, it's easy to do: simply register with
   ivo://votech.org/votable/selectCols#create_plot
   ivo://votech.org/votable/selectCols#overwrite_plot
   ivo://votech.org/votable/selectCols#new_subset

   and all compliant apps pick up the new option automatically.

   This is _almost_ implementable without breaking any existing apps.  
   Since there's no selectCols message yet, there's no reason why we can't 
   define
   selectCols#plot and selectCols#new_subset as distinct messages under the 
   current version of Plastic.  Changing the hub to route messages while 
   ignoring the fragment is, of course, a change to the spec, but I don't 
   think it breaks anything since no currently defined messages use the "#" 
   symbol.

   Comments?

I think this provides an excellent solution - the point being that it's
the responder not the sender which knows what are the options for 
processing a particular kind of data.  So for this case GAIA would 
claim to support the following messages:

   ivo://votech.org/votable/loadFromURL#load_catalogue
   ivo://votech.org/votable/loadFromURL#load_polarimetry

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
[log in to unmask] +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/