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

[Mike Fitzpatrick]

> > 	- tasks must implicitly assume that a base message of a particuar
> > 	  type means it should create a menu entry e.g. only do this for
> >          the process.table.votable messages
> 
> No application has to respond like this.  But applications which are
> already offering to send the message as a menu option (or in some 
> other user-driven way) 

	Ahh, but my app isn't offerring you specifically a menu option
(unless you're saying that's implicitly what the annotation means), I'm
just advertising a capability for a particular message.  *You're* app is
choosing to make that a menu option and not some optional command of a
pipeline system.  So, if I advertise 100 annotations on an mtype and your
app makes menus out of that mtype, you get 100 items.  And, if we don't
have a controlled vocabulary of annotations or mtypes, then how can your
app understand the message and know whether it more properly belongs in a
'File' menu or an 'Analysis' menu option (e.g. because I put the 'load'
annotation on both a file.something and a display.something mtype)?
	I prefer the idea of an app developer deciding which messages they
may want to implement as a GUI option rather some other developer
broadcasting a message saying this is what they think belongs in a menu.
But how do we write this in the spec so that it's clear to both the sender
and receiver what the annotation means, and that if you send me back that
message I require a filename for one and an aperture radius about a
central position for another?
	I guess I'm stuck on the notion that annotations are being
described as a general feature but appear to have a very specific use
(i.e. to describe a capability in a user interface).  Can we simplify this
by limiting the use of annotations to UI usage so we can define what the
sender and receiver need to do with them?


-Mike