x-samp namespace suggestion
luigi at lambrate.inaf.it
Fri Sep 23 02:07:45 PDT 2011
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)
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:
> - the VOResource identifier of the application, if registered in VO
> 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
> 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.
More information about the apps-samp