x-samp namespace suggestion

Tue Sep 27 09:39:04 PDT 2011

Thanks for the work you’re putting into this, Mark!

One question: why saying MAY here?

The ``{\tt samp}'' and ``{\tt x-samp}'' form of the same key
SHOULD NOT be presented in the same map, but if they are,
the ``{\tt samp}'' form MAY be considered to take precedence.

As far as I see it, that MAY should be a SHOULD, to allow for predictability.

I cannot foresee an scenario where a client would do different for x-samp.X than for samp.X, outside of system prototyping that should not reach users...

El 27/09/2011, a las 18:25, Mark Taylor escribió:

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

--
Juande Santander Vela
Software Engineer, ALMA Archive Subsystem
Data Flow Infrastructure Department, Software Development Division
European Southern Observatory (Germany)