x-samp namespace suggestion

[Sylvain LAFRASSE]

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

It sounds a litlle bit conservatve to me, but should be a a good workaround to the heavy standard updating process.

>    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)?

Our point was twofold.
The straight forward one is that samp.application.name should be MANDATORY.
Then, our projects would need a keyword to point to a download page for any application (preferably a JNLP URL ;). The definite solution would of course be having a universal app identifier that points to a registry entry with all the application details !

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

Definitely :)

Best regards,
Sylvain


On 23 sept. 2011, at 11:07, Luigi Paioro wrote:

> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/apps-samp/attachments/20110927/d48d3265/attachment-0001.html>