x-samp namespace suggestion

[Mark Taylor]

Hi sampers,

as I reported recently, the SAMP 1.3 document is currently in PR and
shortly scheduled for RFC.  However, following some suggestions from
the team at JMMC (Laurent Bourges and Sylvain Lafrasse), and subsequent
thoughts of mine, I think maybe there are one or two changes that ought
to be made first.

The JMMC team are working on a SAMP application launcher which has
a requirement for some additional standard metadata to be defined
alongside the items listed in section 3.6 of the standard
(samp.name, samp.icon.url etc.).  This may be a JNLP URL or an
ivo URI pointing to a registry resource describing the application
or possibly both or something else.  Laurent suggested the
following new metadata item:

   *samp.application.identifier*
      - the VOResource identifier of the application, if registered in VO
      registries

That sounds reasonable enough to me.  However, though it will probably
be defined at some point, the relevant ApplicationRegExt registry
extension does not yet exist, so it might be premature to reference
it in the SAMP standard now.  When it is eventually defined, the details
of the definition may mean that an entry like this ends up not doing
what's needed.  So it might be better to defer the decision until
later.  On the other hand, updating the standard is a heavyweight
process and we don't want to do it just for a change like adding
a new metadata item.

Since the Application Metadata uses an extensible vocabulary
(see SAMP section 2.6) it's quite permissible to add new non-standard
keys to it containing new information, which don't require changes
to the standard.  However, according to the rules, only keys 
defined in the standard itself are allowed to use the reserved 
samp.* namespace.  Some other namespace (app, client, jmmc, ..)
could be used, but if SAMP applications start using these,
they can't be easily incorporated into the standard, since all
the official keys are supposed to use the samp.* namespace.
This is actually a general problem with incorporating official
changes to the extensible vocabularies which SAMP uses in 
various places.

So I suggest a convention in which the namespace "x-samp" indicates
an entry which may make its way (in the "samp" namespace) into the
standard in the future.  The "x-" prefix stands for experimental,
and loosely follows the convention used by MIME types).  
Then JMMC could start to use "x-samp.application.identifier" now,
and if experimentation by them and by application authors confirms 
that this should become an official part of the standard, the next
time the standard is updated it can be included as 
"samp.application.identifier".  In the mean time, clients should 
treat the "samp." and "x-samp." forms interchangeably, so that
consumers of these items continue to work when the standard is changed
and producers adopt the officially sanctioned form.  Some text like 
the following could be added to section 2.6 of the standard:

   Non-well-known keys (those outside of the "samp." namespace) fall into
   two categories: those which are candidates for future incorporation
   into the SAMP standard as well-known keys, and those which are not.
   If developers are experimenting with keys which they hope or believe
   may be incorporated into the SAMP standard as well-known at some time
   in the future, they may use the special namespace "x-samp.".
   If a future version of the standard does incorporate such a key as
   well-known, the prefix is simply changed from "x-samp" to "samp".
   Consumers of such keys SHOULD treat the keys "x-samp.a.b" and
   "samp.a.b" identically; the "samp" and "x-samp" form of the same
   key SHOULD NOT be presented together, but if they are, the "samp"
   form takes precedence.  This scheme makes it easy to introduce new
   well-known keys in a way which neither makes illicit use of the
   reserved "samp" namespace nor requires frequent updates to the SAMP
   standard.

It's regrettable that I didn't think of this before submitting the PR,
since to incorporate this change we'd have to resubmit the PR and wait
another two weeks to go to RFC, but that's what the various delays
in the process are there for I suppose.

So, if people have an opinion, please voice it on:

   1. Is the x-samp convention a good idea?

   2. Should the imminent version (1.3) of the standard include a
      new metadata item samp.application-identifier (or something
      else along similar lines, and if so what)?

   3. Should we make these changes to the document now, adding a short
      delay to acceptance time?

My own feelings are 1: yes, 2: no, 3: yes.  I'll make a decision early
next week based on what, if any, responses are posted.  Of course
clarifications or modifications to my suggested text or any other
issues relating to the existing text of the document are welcome too.

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/