x-samp namespace suggestion

[Mark Taylor]

Thanks for the responses to this.  Since they have been basically positive,
I've made the relevant changes to the document text.
This is volute rev 1594 - for diffs see:

   http://code.google.com/p/volute/source/diff?spec=svn1594&r=1594&format=side&path=/trunk/projects/samp/doc/samp.tex&old_path=/trunk/projects/samp/doc/samp.tex&old=1556

Any comments on the detail welcome.

If I resubmitted the PR now, the RFC would begin only just before
the Pune Interop.  So, I think I'll hold off until after the Interop,
in case discussions there lead to further significant changes.
I would then plan to submit the PR, possibly with further changes,
just after the Interop.

In fact, this is pretty much what I said after the last Interop - 
oh well, better to have it right than soon I think.

Mark


On Tue, 20 Sep 2011, Mark Taylor wrote:

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

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