# ISSUE: Annotatations

Mark Taylor m.b.taylor at bristol.ac.uk
Wed Apr 30 03:44:23 PDT 2008

Message "Annotations" are a mechanism intended to allow dynamic runtime
refinement of MType semantics while using exactly the same syntax.
They were discussed but not much used within PLASTIC.
There has been considerable debate over whether annotations
are a useful feature.  We need to discuss whether, and if so how,
to incorporate this feature into SAMP (the mechanism might be a bit
different from that proposed within PLASTIC since it is not under
the same constraints of backward compatibility).

The current version of the draft document does not discuss annotations,
but a description from an earlier draft ran as follows:

\subsection{Message Annotations}
\label{sect:msgAnnotate}

Message annotations allow recipients of messages to {\em annotate}
Mtypes in order to narrow down the semantics, without changing the syntax
of the message.  In this way, messages semantics can be dynamically
extended/narrowed down without penalizing senders who do not understand
the ad-hoc annotations.  Annotation strings are dynamically created by
applications and may be declared as newly supported Mtypes any time after
the application has registered with the Hub.

The syntax for an annotation is as follows:

\begin{verbatim}
<mtype> '@' <annotation>
\end{verbatim}

As an example, consider an application (A) that has registered and declared
support for the {\em process.votable} Mtype.  Upon loading a new table, that
application can declare support for the new annotated Mtype
{\em process.votable at append}.  The Hub will notify interested clients of this
new capability, and a different application (B) may choose to create a menu
of similar options using the root {process.votable} as a default action,
and the annotated Mtype to invoke a specific behavior.  Application B doesn't
need to know specifically what the annotation means, but by sending it back
to application A using the same arguments as for the base Mtype, application
A is able to dynamically extend the Mtype to create a specific functionality.

Applications SHOULD be able to parse annotated Mtypes, however they
are free to ignore annotations they do not understand and process only the
base Mtype (if supported).

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