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

[Mark Taylor]

Hi Mike,

On Thu, 3 May 2007, Mike Fitzpatrick wrote:

>>> 	- 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)?

Because the idea of annotations is explicitly intended to exclude
(attempts at) semantic interpretation or controlled vocabularies, 
it would be wrong to (attempt to) make semantically-based decisions 
about which menus to put these things in (though I reiterate, putting 
such options in menus is only one way to respond to such annotations).

> 	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.

If you prefer that idea - then fine, you can define mtypes along those
lines which are not designed to be annotated.  There has never been
any intention to use annotations for all (or even most or many) purposes.
Howerver, for some cases (especially those where the distinction between 
different actions that can be taken is so application-specific that 
it would be hopeless to try to capture them in some generic controlled 
vocabulary) I believe this provides the neatest solution. 
If you don't share that belief, then don't advertise different annotations 
of any messages which you receive, and don't respond to multiple alternative
annotations of given messages advertised by other applications - 
this is quite reasonable behaviour and does not prevent you from
participating in the messaging conversation.

> 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?

What I've been trying to say about the distinction between message
syntax and message semantics is that it will *never* be the case that
one annotation of a given mtype requires a filename argument while another
requires an aperture radius argument.  Different annotations of the
same message *always* require precisely the same arguments.  If you 
want different arguments you *must* use different mtypes and not 
different annotations of the same mtype.

> 	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?

They are syntactically general, but it doesn't mean that you'd have to,
want to, or know how to use them for everything, or even many things.
You may use them for very few messages, or none at all.  But I see no 
benefit, and certainly no simplification, arising from restricting 
their use to certain semantic regions of the mtype vocabulary 
(e.g. UI issues).

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/