x-samp namespace suggestion

Mark Taylor m.b.taylor at bristol.ac.uk
Tue Sep 27 10:08:48 PDT 2011 

Juande,

thanks for the careful reading.

On Tue, 27 Sep 2011, Juande Santander Vela wrote:

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

My thinking was to reduce the burden on implementors, in cases where
the outcome doesn't really matter.  If a map with both keys is presented, 
whoever produced it has done something wrong, and the consumer 
shouldn't be expected to put much effort into behaving properly;
the MAY is just there to give a hint which way to jump if somebody 
wants to try hard to do the right thing, but in any case doing either
is likely to be reasonable.  If it was SHOULD, then client authors 
(with a conscience) might have to spend effort dealing with a case 
which is unlikely to occur.

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

Some kind of bug is the most likely cause; but agreed, it is not
expected to happen.

Mark

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

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

More information about the apps-samp mailing list