Annotations [was Re: Apps Messaging -- A New Approach

[Mike Fitzpatrick]

> >> Persumably we
> >> would need a small, controlled vocabulary for these annotations to be
> >> meaningful to machines, and apps would be free to make up their own.
> >
> > No, the vocabulary for annotations is completely uncontrolled,
> > applications always make up their own.  For a controlled vocabulary
> > you'd stick to the message type (opaque URI in PLASTIC, perhaps  
> > mtype in
> > future).
> 
> I think this is the essential difference, and that the annotations  
> can be made up dynamically.  Here's an (albeit contrived) example.   
> You've loaded a VOTable into Topcat, called "table1".  Topcat  
> immediately declares to the world that it supports a new message:
> 
> process.table.votable at append_to_table1.
> 
> All the other applications on the user's desktop now magically have a  
> new option in their menus.  Assuming that they have a table ready  
> that they can send to other applications, they will have the option  
> "table2->topcat->append to table 1"
> No long discussion on this list required.  You don't even need to  
> recompile.  Or even restart.

	I'm not sure 'magical' is quite the right word, this is very much 
a designed interaction in a task that 1) knows TOPCAT can/may issue an
'append_to_table1' annotation and 2) that receiving that annotation means 
the app should restructure its menus accordingly.  Magic is when I can 
send the uncontrolled 'apTab1' annotation from my task and get the same 
effect.



-Mike