x-samp namespace suggestion

[Luigi Paioro]

Hi Mark,

I fully agree with you:

   o I think x-samp convention is a good idea
   o I wouldn't include samp.application-identifier in the standard
     (at least not yet)
   o we should make the change as soon as possible (2 or 3 weeks are not
     such a big delay)

Regards,

   Luigi


Il 09/20/11 14:00, Mark Taylor ha scritto:
> 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