From m.b.taylor at bristol.ac.uk Mon Sep 12 05:16:01 2011 From: m.b.taylor at bristol.ac.uk (Mark Taylor) Date: Mon, 12 Sep 2011 13:16:01 +0100 (BST) Subject: SAMP 1.3 PR Message-ID: Hi all, since no issues have been raised with the 2011-07-28 SAMP 1.3 WD, I've now submitted it as a Proposed Recommendation (2011-09-05), available from the IVOA Docs page. Following the statutory two-week period, I will announce the start of the RFC stage shortly, with the intention that it can conclude following the Pune Interop. 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/ From m.b.taylor at bristol.ac.uk Tue Sep 20 05:00:55 2011 From: m.b.taylor at bristol.ac.uk (Mark Taylor) Date: Tue, 20 Sep 2011 13:00:55 +0100 (BST) Subject: x-samp namespace suggestion Message-ID: 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/ From luigi at lambrate.inaf.it Fri Sep 23 02:07:45 2011 From: luigi at lambrate.inaf.it (Luigi Paioro) Date: Fri, 23 Sep 2011 11:07:45 +0200 Subject: x-samp namespace suggestion In-Reply-To: References: Message-ID: <4E7C4C61.3060102@lambrate.inaf.it> 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 From sylvain.lafrasse at obs.ujf-grenoble.fr Tue Sep 27 06:13:59 2011 From: sylvain.lafrasse at obs.ujf-grenoble.fr (Sylvain LAFRASSE) Date: Tue, 27 Sep 2011 15:13:59 +0200 Subject: x-samp namespace suggestion In-Reply-To: <4E7C4C61.3060102@lambrate.inaf.it> References: <4E7C4C61.3060102@lambrate.inaf.it> Message-ID: <282AB18E-5D71-4183-B376-425774BB0625@obs.ujf-grenoble.fr> > 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: From m.b.taylor at bristol.ac.uk Tue Sep 27 09:16:28 2011 From: m.b.taylor at bristol.ac.uk (Mark Taylor) Date: Tue, 27 Sep 2011 17:16:28 +0100 (BST) Subject: x-samp namespace suggestion In-Reply-To: <282AB18E-5D71-4183-B376-425774BB0625@obs.ujf-grenoble.fr> References: <4E7C4C61.3060102@lambrate.inaf.it> <282AB18E-5D71-4183-B376-425774BB0625@obs.ujf-grenoble.fr> Message-ID: On Tue, 27 Sep 2011, Sylvain LAFRASSE wrote: > > 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. A mandatory metadata item does not make much sense, since clients are not obliged to declare metadata at all. Of the existing metadata items, none is mandatory, but samp.name is "strongly RECOMMENDED", and as far as I know nearly all clients provide it. If your tool has a requirement for one or more particular metadata items, it seems reasonable that it just won't work for clients which don't provide them. > 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 ! Given that we go ahead with the x-samp business, you could suggest one or more metadata keys and the SAMP community could experiment with adopting them. If they look like they are useful, we can make them official in a future version of the standard. I've added a new wiki page http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/SampXSamp for listing/discussing such things. 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/ From m.b.taylor at bristol.ac.uk Tue Sep 27 09:25:03 2011 From: m.b.taylor at bristol.ac.uk (Mark Taylor) Date: Tue, 27 Sep 2011 17:25:03 +0100 (BST) Subject: x-samp namespace suggestion In-Reply-To: References: Message-ID: 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/ From juandesant at gmail.com Tue Sep 27 09:39:04 2011 From: juandesant at gmail.com (Juande Santander Vela) Date: Tue, 27 Sep 2011 18:39:04 +0200 Subject: x-samp namespace suggestion In-Reply-To: References: Message-ID: <640CC5CE-E9F7-4038-AFA6-4E5B8E4EF991@gmail.com> 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) From m.b.taylor at bristol.ac.uk Tue Sep 27 10:08:48 2011 From: m.b.taylor at bristol.ac.uk (Mark Taylor) Date: Tue, 27 Sep 2011 18:08:48 +0100 (BST) Subject: x-samp namespace suggestion In-Reply-To: <640CC5CE-E9F7-4038-AFA6-4E5B8E4EF991@gmail.com> References: <640CC5CE-E9F7-4038-AFA6-4E5B8E4EF991@gmail.com> Message-ID: 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/ From juandesant at gmail.com Wed Sep 28 04:39:02 2011 From: juandesant at gmail.com (Juande Santander Vela) Date: Wed, 28 Sep 2011 13:39:02 +0200 Subject: x-samp namespace suggestion In-Reply-To: References: <640CC5CE-E9F7-4038-AFA6-4E5B8E4EF991@gmail.com> Message-ID: <719B0B06-7EBD-47DB-84EE-0746FF83467B@gmail.com> Mark, thanks for the clarification. I think the ?in any case either is likely to be reasonable? makes for a good case for the MAY, but I think it could be spelled out in the sentence, something like: 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 the final behaviour is likely to be reasonable. But now I see why it does not make a difference in behaviour, and it alleviates implementors? burden. El 27/09/2011, a las 19:08, Mark Taylor escribi?: > 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. -- Juande Santander Vela Software Engineer, ALMA Archive Subsystem Data Flow Infrastructure Department, Software Development Division European Southern Observatory (Germany) An?nimo: A veces es necesario guardar silencio para ser escuchado. From m.b.taylor at bristol.ac.uk Wed Sep 28 05:07:04 2011 From: m.b.taylor at bristol.ac.uk (Mark Taylor) Date: Wed, 28 Sep 2011 13:07:04 +0100 (BST) Subject: x-samp namespace suggestion In-Reply-To: <719B0B06-7EBD-47DB-84EE-0746FF83467B@gmail.com> References: <640CC5CE-E9F7-4038-AFA6-4E5B8E4EF991@gmail.com> <719B0B06-7EBD-47DB-84EE-0746FF83467B@gmail.com> Message-ID: OK a clarification is a good idea. How about: The ``{\tt samp}'' and ``{\tt x-samp}'' form of the same key SHOULD NOT be presented in the same map. If both are presented together, the ``{\tt samp}'' form MAY be considered to take precedence, though any reasonable behaviour is permitted. ? On Wed, 28 Sep 2011, Juande Santander Vela wrote: > Mark, thanks for the clarification. > > I think the ?in any case either is likely to be reasonable? makes for a good case for the MAY, but I think it could be spelled out in the sentence, something like: > > 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 the final behaviour is likely to be reasonable. > > But now I see why it does not make a difference in behaviour, and it alleviates implementors? burden. > > El 27/09/2011, a las 19:08, Mark Taylor escribi?: > > > 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. > > -- > Juande Santander Vela > Software Engineer, ALMA Archive Subsystem > Data Flow Infrastructure Department, Software Development Division > European Southern Observatory (Germany) > > An?nimo: A veces es necesario guardar silencio para ser escuchado. > > -- 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/ From juandesant at gmail.com Wed Sep 28 05:50:32 2011 From: juandesant at gmail.com (Juande Santander Vela) Date: Wed, 28 Sep 2011 14:50:32 +0200 Subject: x-samp namespace suggestion In-Reply-To: References: <640CC5CE-E9F7-4038-AFA6-4E5B8E4EF991@gmail.com> <719B0B06-7EBD-47DB-84EE-0746FF83467B@gmail.com> Message-ID: That?s perfectly fine, and much better worded than my version. Thanks! El 28/09/2011, a las 14:07, Mark Taylor escribi?: > OK a clarification is a good idea. How about: > > The ``{\tt samp}'' and ``{\tt x-samp}'' form of the same key > SHOULD NOT be presented in the same map. If both are presented together, > the ``{\tt samp}'' form MAY be considered to take precedence, > though any reasonable behaviour is permitted. > > ? -- Juande Santander Vela Software Engineer, ALMA Archive Subsystem Data Flow Infrastructure Department, Software Development Division European Southern Observatory (Germany) Arthur C. Clarke: La ?nica manera de descubrir los l?mites de lo posible es aventur?ndose un poco hasta lo imposible. From bourges.laurent at gmail.com Thu Sep 29 02:14:24 2011 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Thu, 29 Sep 2011 11:14:24 +0200 Subject: x-samp namespace suggestion In-Reply-To: References: <4E7C4C61.3060102@lambrate.inaf.it> <282AB18E-5D71-4183-B376-425774BB0625@obs.ujf-grenoble.fr> Message-ID: Dear all, few comments below: 2011/9/27 Mark Taylor : > On Tue, 27 Sep 2011, Sylvain LAFRASSE wrote: > >> > ? ?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. Agreed. I propose also to have one wiki page giving the complete list of application meta data keywords used among all SAMP applications worldwide. I am convinced that such keywords are subject to change that's why it can become boring / difficult to maintain the SAMP standard document every time a new keyword is needed. What do you think to externalize this part of the specification (section 3.6) into one wiki page that will act as one official extension of the SAMP standard ? >> >> > ? ?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. > > A mandatory metadata item does not make much sense, since clients > are not obliged to declare metadata at all. ?Of the existing metadata > items, none is mandatory, but samp.name is "strongly RECOMMENDED", > and as far as I know nearly all clients provide it. ?If your tool > has a requirement for one or more particular metadata items, it seems > reasonable that it just won't work for clients which don't > provide them. As you said: "as far as I know nearly all clients provide it", I propose to modify the standard to make application meta data MANDATORY with at least (samp.application.name and x-samp.application.identifier) and one new recommended keyword x-samp.application.link that points to an URI describing the application (home page for example). > >> 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 ! We also need - as sylvain said - the JNLP (Java web start application) URL; I propose the keyword x-samp.application.link.jnlp > > Given that we go ahead with the x-samp business, you could suggest > one or more metadata keys and the SAMP community could experiment > with adopting them. ?If they look like they are useful, we can > make them official in a future version of the standard. > I've added a new wiki page > http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/SampXSamp > for listing/discussing such things. Great; maybe someone (mark ? us at jmmc) should gather all known non-standard keywords into such wiki pages to propose new xsamp keywords ... I mean topcat, aladin and our applications already use non-standard keywords curation (affiliation, author, email), description (home page, documentation / support web pages ...) and one very important: application.version (public, beta, 0.9.0 ...) Best regards, Laurent From m.b.taylor at bristol.ac.uk Thu Sep 29 02:52:29 2011 From: m.b.taylor at bristol.ac.uk (Mark Taylor) Date: Thu, 29 Sep 2011 10:52:29 +0100 (BST) Subject: x-samp namespace suggestion In-Reply-To: References: <4E7C4C61.3060102@lambrate.inaf.it> <282AB18E-5D71-4183-B376-425774BB0625@obs.ujf-grenoble.fr> Message-ID: On Thu, 29 Sep 2011, Laurent Bourg?s wrote: > Dear all, > > few comments below: > > 2011/9/27 Mark Taylor : > > On Tue, 27 Sep 2011, Sylvain LAFRASSE wrote: > > > >> > ? ?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. > > Agreed. I propose also to have one wiki page giving the complete list > of application meta data keywords used among all SAMP applications > worldwide. I am convinced that such keywords are subject to change > that's why it can become boring / difficult to maintain the SAMP > standard document every time a new keyword is needed. What do you > think to externalize this part of the specification (section 3.6) into > one wiki page that will act as one official extension of the SAMP > standard ? Having an external wiki page is a good idea, but I wouldn't externalise the whole thing - I still think it makes sense to split the metadata keys (and other cases where extensible vocabularies are used) into three basic categories: 1. samp.*: Well-known, agreed, stable, will not change 2. x-samp.*: Suggested for possible future promotion to samp.* 3. (others): Used by some clients, but no requirement to be well-known Items in classes 1 and 2 are intended for programmatic manipulation by general SAMP clients that understand their semantics; for instance the samp.name and samp.icon.url will often be used to identify a client to users in a GUI. Items in class 3 fall into two categories: either they are intended for use by other "friendly" applications, by arrangement between the developers involved, or they are intended mainly for human consumption. Something like TOPCAT's author.affiliation is intentionally in category 3; it's just there for interested readers, it's not expected that SAMP hubs/clients will do anything special with this other than present it as an opaque piece of metadata to human users or other consumers. So I think class 1 should stay defined within the SAMP standard. Class 2 should have their own wiki page, I've set up the page SampXSamp (http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/SampXSamp) as a placeholder for this, it should perhaps be subdivided for the different vocabularies (metadata keys, lockfile keys, etc). I don't think there's much value in trying to standardise all possible metadata keys (or other vocabulary items). Whether a particular item (such as software version) belongs in class 2 or 3 is a question which can be argued separately, but my feeling is that unless there is some specific reason that software needs to understand the semantics of a particular item, there is little value in standardising it. Items like JNLP URL are clearly in class 2, since to be useful, clients have to know how to find it. > >> > ? ?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. > > > > A mandatory metadata item does not make much sense, since clients > > are not obliged to declare metadata at all. ?Of the existing metadata > > items, none is mandatory, but samp.name is "strongly RECOMMENDED", > > and as far as I know nearly all clients provide it. ?If your tool > > has a requirement for one or more particular metadata items, it seems > > reasonable that it just won't work for clients which don't > > provide them. > > As you said: "as far as I know nearly all clients provide it", I > propose to modify the standard to make application meta data MANDATORY > with at least (samp.application.name and > x-samp.application.identifier) and one new recommended keyword > x-samp.application.link that points to an URI describing the > application (home page for example). We can't make x-samp.application.identifier mandatory at the moment, since the ApplicationRegExt standard that it would need to make sense doesn't exist yet. I think it would be a bad idea in any case, since you might just put together a tiny temporary test client for which it makes no sense to have an application registration. > >> 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 ! > > We also need - as sylvain said - the JNLP (Java web start application) > URL; I propose the keyword x-samp.application.link.jnlp > > > > > Given that we go ahead with the x-samp business, you could suggest > > one or more metadata keys and the SAMP community could experiment > > with adopting them. ?If they look like they are useful, we can > > make them official in a future version of the standard. > > I've added a new wiki page > > http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/SampXSamp > > for listing/discussing such things. > > Great; maybe someone (mark ? us at jmmc) should gather all known > non-standard keywords into such wiki pages to propose new xsamp > keywords ... > > I mean topcat, aladin and our applications already use non-standard > keywords curation (affiliation, author, email), description (home > page, documentation / support web pages ...) and one very important: > application.version (public, beta, 0.9.0 ...) If you want to collate this list and suggest corresponding x-samp keys on or near the SampXSamp wiki page then go ahead. As I say I feel that standardisation only brings benefits for those keys for which clients have some need of semantic understanding. Probably some of the keys currently in use do fall into that category, but I'm sure some don't. 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/ From bourges.laurent at gmail.com Fri Sep 30 00:49:46 2011 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Fri, 30 Sep 2011 09:49:46 +0200 Subject: x-samp namespace suggestion In-Reply-To: References: <4E7C4C61.3060102@lambrate.inaf.it> <282AB18E-5D71-4183-B376-425774BB0625@obs.ujf-grenoble.fr> Message-ID: Thanks for your prompt answer; here are my comments in the text: 2011/9/29 Mark Taylor : >> >> 2011/9/27 Mark Taylor : >> > On Tue, 27 Sep 2011, Sylvain LAFRASSE wrote: >> > >> >> > ? ?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. >> >> Agreed. I propose also to have one wiki page giving the complete list >> of application meta data keywords used among all SAMP applications >> worldwide. I am convinced that such keywords are subject to change >> that's why it can become boring / difficult to maintain the SAMP >> standard document every time a new keyword is needed. What do you >> think to externalize this part of the specification (section 3.6) into >> one wiki page that will act as one official extension of the SAMP >> standard ? > > Having an external wiki page is a good idea, but I wouldn't externalise > the whole thing - I still think it makes sense to split the metadata > keys (and other cases where extensible vocabularies are used) into > three basic categories: > > ? 1. samp.*: > ? ? ? Well-known, agreed, stable, will not change > ? 2. x-samp.*: > ? ? ? Suggested for possible future promotion to samp.* > ? 3. (others): > ? ? ? Used by some clients, but no requirement to be well-known > > Items in classes 1 and 2 are intended for programmatic manipulation > by general SAMP clients that understand their semantics; for instance > the samp.name and samp.icon.url will often be used to identify a > client to users in a GUI. > Items in class 3 fall into two categories: either they are intended > for use by other "friendly" applications, by arrangement between > the developers involved, or they are intended mainly for human > consumption. ?Something like TOPCAT's author.affiliation is > intentionally in category 3; it's just there for interested readers, > it's not expected that SAMP hubs/clients will do anything special with > this other than present it as an opaque piece of metadata to human > users or other consumers. > > So I think class 1 should stay defined within the SAMP standard. Ok > Class 2 should have their own wiki page, I've set up the page > SampXSamp (http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/SampXSamp) > as a placeholder for this, it should perhaps be subdivided for the > different vocabularies (metadata keys, lockfile keys, etc). > I don't think there's much value in trying to standardise all > possible metadata keys (or other vocabulary items). I think it is worth to indicate possible keywords in order to let developpers reuse some of them. For example, the contact (email) could be useful to let the user send an email to the application's author ... > Whether a particular item (such as software version) belongs in > class 2 or 3 is a question which can be argued separately, but > my feeling is that unless there is some specific reason that > software needs to understand the semantics of a particular item, > there is little value in standardising it. ?Items like JNLP URL > are clearly in class 2, since to be useful, clients have to > know how to find it. Ok; let's fill the wiki SampXSamp ... > >> >> > ? ?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. >> > >> > A mandatory metadata item does not make much sense, since clients >> > are not obliged to declare metadata at all. ?Of the existing metadata >> > items, none is mandatory, but samp.name is "strongly RECOMMENDED", >> > and as far as I know nearly all clients provide it. ?If your tool >> > has a requirement for one or more particular metadata items, it seems >> > reasonable that it just won't work for clients which don't >> > provide them. >> >> As you said: "as far as I know nearly all clients provide it", I >> propose to modify the standard to make application meta data MANDATORY >> with at least (samp.application.name and >> x-samp.application.identifier) and one new recommended keyword >> x-samp.application.link that points to an URI describing the >> application (home page for example). My proposal has two aspects: 1/ change SAMP standard section 3.6: make application meta data MANDATORY with at least the keyword samp.application.name which becomes REQUIRED) 2/ In my proposal, I just want one new keyword x-samp.application.identifier containing only alpha numeric characters in upper case [ASPRO2] that is related to the application name but is an identifier (no white space / punctuation characters) in order to let SAMP client application identify one specific application without parsing its name (free field - unspecified) that can evolve or contain variable information like: - "Aspro 2" (upper case and lower case) - "Aspro 2 - 0.9.1" (name and version) If you prefer you can modify the SAMP standard to impose constraints on samp.application.name ... > > We can't make x-samp.application.identifier mandatory at the moment, > since the ApplicationRegExt standard that it would need to make sense > doesn't exist yet. ?I think it would be a bad idea in any case, since > you might just put together a tiny temporary test client for which it > makes no sense to have an application registration. In the future (i.e. when the AppRegExt will be one public IVOA standard), another identifier could emerge like x-samp.application.ivoId containing one valid ivoId value (see xml type for its format) > >> >> 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 ! >> >> We also need - as sylvain said - the JNLP (Java web start application) >> URL; I propose the keyword x-samp.application.link.jnlp >> >> > >> > Given that we go ahead with the x-samp business, you could suggest >> > one or more metadata keys and the SAMP community could experiment >> > with adopting them. ?If they look like they are useful, we can >> > make them official in a future version of the standard. >> > I've added a new wiki page >> > http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/SampXSamp >> > for listing/discussing such things. >> >> Great; maybe someone (mark ? us at jmmc) should gather all known >> non-standard keywords into such wiki pages to propose new xsamp >> keywords ... >> >> I mean topcat, aladin and our applications already use non-standard >> keywords curation (affiliation, author, email), description (home >> page, documentation / support web pages ...) and one very important: >> application.version (public, beta, 0.9.0 ...) > > If you want to collate this list and suggest corresponding x-samp > keys on or near the SampXSamp wiki page then go ahead. > As I say I feel that standardisation only brings benefits for those > keys for which clients have some need of semantic understanding. > Probably some of the keys currently in use do fall into that category, > but I'm sure some don't. According to me, it is often difficult to guess the developper needs or usages i.e. probably several clients could need keywords having the same semantic meaning like author, email ... that's why it will be very useful to let developpers inform others using the Samp wiki page which official and unofficial keywords are defined. Regards, Laurent From m.b.taylor at bristol.ac.uk Fri Sep 30 01:56:45 2011 From: m.b.taylor at bristol.ac.uk (Mark Taylor) Date: Fri, 30 Sep 2011 09:56:45 +0100 (BST) Subject: x-samp namespace suggestion In-Reply-To: References: <4E7C4C61.3060102@lambrate.inaf.it> <282AB18E-5D71-4183-B376-425774BB0625@obs.ujf-grenoble.fr> Message-ID: Hi Laurent, On Fri, 30 Sep 2011, Laurent Bourg?s wrote: > > Class 2 should have their own wiki page, I've set up the page > > SampXSamp (http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/SampXSamp) > > as a placeholder for this, it should perhaps be subdivided for the > > different vocabularies (metadata keys, lockfile keys, etc). > > I don't think there's much value in trying to standardise all > > possible metadata keys (or other vocabulary items). > > I think it is worth to indicate possible keywords in order to let > developpers reuse some of them. For example, the contact (email) could > be useful to let the user send an email to the application's author > ... Yes but ... it only needs standardisation if the consumer of that metadata item is a machine and not a human. In the case of the email that means if the software is going to offer a button labelled "mail the author of this software". If we're going to allow that, then really it's not sufficient to have the author email address because that might not be an appropriate recipient for general emails, so we should also define a mailing list support address if one exists, or maybe there's no email but a WWW page with a form for queries etc... it gets complicated both in the definitions and in the usage. If it's not mediated by software, then a human is quite capable of looking through the metadata list - which is intended to be human-readable - and spotting something that looks like a suitable email address or other contact point if one exists, and standardisation is not required. There might be other examples of metadata keywords which could benefit from this kind of standardisation, but I can't think of (m)any. Arguably, we have already defined too many - of the 5 samp.* application metadata items in sec 3.6, I don't think that samp.description.text or (especially) samp.description.html are widely used, though I am not suggesting we remove them. > > Whether a particular item (such as software version) belongs in > > class 2 or 3 is a question which can be argued separately, but > > my feeling is that unless there is some specific reason that > > software needs to understand the semantics of a particular item, > > there is little value in standardising it. ?Items like JNLP URL > > are clearly in class 2, since to be useful, clients have to > > know how to find it. > > Ok; let's fill the wiki SampXSamp ... yes. > >> >> > ? ?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. > >> > > >> > A mandatory metadata item does not make much sense, since clients > >> > are not obliged to declare metadata at all. ?Of the existing metadata > >> > items, none is mandatory, but samp.name is "strongly RECOMMENDED", > >> > and as far as I know nearly all clients provide it. ?If your tool > >> > has a requirement for one or more particular metadata items, it seems > >> > reasonable that it just won't work for clients which don't > >> > provide them. > >> > >> As you said: "as far as I know nearly all clients provide it", I > >> propose to modify the standard to make application meta data MANDATORY > >> with at least (samp.application.name and > >> x-samp.application.identifier) and one new recommended keyword > >> x-samp.application.link that points to an URI describing the > >> application (home page for example). > > My proposal has two aspects: > 1/ change SAMP standard section 3.6: make application meta data > MANDATORY with at least the keyword samp.application.name which > becomes REQUIRED) Given that samp.application.name is already strongly RECOMMENDED I don't follow what purpose making it mandatory would serve. Of course, clients which do not supply this metadata must not be surprised if some things don't work well. In some cases they don't care: for instance a small non-callable client which just registers, sends a message, and unregisters. I'd say it's good practice even for that to supply a name, but if it doesn't, why does it matter? > 2/ In my proposal, I just want one new keyword > x-samp.application.identifier containing only alpha numeric characters > in upper case [ASPRO2] that is related to the application name but is > an identifier (no white space / punctuation characters) in order to > let SAMP client application identify one specific application without > parsing its name (free field - unspecified) that can evolve or contain > variable information like: > - "Aspro 2" (upper case and lower case) > - "Aspro 2 - 0.9.1" (name and version) > > If you prefer you can modify the SAMP standard to impose constraints > on samp.application.name ... samp.application.name already is already defined as: "A one word title for the application" The case is not specified (why should it be?), and it may or may not be an identifier in any given syntax, but given that it's one word I don't think you'd expect it to change/evolve for (e.g. different versions of) the same application. So, I think it's suitable for use as an opaque token for string matching. Are there any further constraints you'd like to suggest for the definition? > > We can't make x-samp.application.identifier mandatory at the moment, > > since the ApplicationRegExt standard that it would need to make sense > > doesn't exist yet. ?I think it would be a bad idea in any case, since > > you might just put together a tiny temporary test client for which it > > makes no sense to have an application registration. > > In the future (i.e. when the AppRegExt will be one public IVOA > standard), another identifier could emerge like > x-samp.application.ivoId containing one valid ivoId value (see xml > type for its format) OK yes. > >> >> 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 ! > >> > >> We also need - as sylvain said - the JNLP (Java web start application) > >> URL; I propose the keyword x-samp.application.link.jnlp > >> > >> > > >> > Given that we go ahead with the x-samp business, you could suggest > >> > one or more metadata keys and the SAMP community could experiment > >> > with adopting them. ?If they look like they are useful, we can > >> > make them official in a future version of the standard. > >> > I've added a new wiki page > >> > http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/SampXSamp > >> > for listing/discussing such things. > >> > >> Great; maybe someone (mark ? us at jmmc) should gather all known > >> non-standard keywords into such wiki pages to propose new xsamp > >> keywords ... > >> > >> I mean topcat, aladin and our applications already use non-standard > >> keywords curation (affiliation, author, email), description (home > >> page, documentation / support web pages ...) and one very important: > >> application.version (public, beta, 0.9.0 ...) > > > > If you want to collate this list and suggest corresponding x-samp > > keys on or near the SampXSamp wiki page then go ahead. > > As I say I feel that standardisation only brings benefits for those > > keys for which clients have some need of semantic understanding. > > Probably some of the keys currently in use do fall into that category, > > but I'm sure some don't. > > According to me, it is often difficult to guess the developper needs > or usages i.e. probably several clients could need keywords having the > same semantic meaning like author, email ... that's why it will be > very useful to let developpers inform others using the Samp wiki page > which official and unofficial keywords are defined. Yes, you're right. if it becomes clear that some of the existing keys (or some new ones) really would benefit from standardisation, we can go ahead with that. Letting these things arise from successful usage patterns rather then decreeing up front how people are going to do things is IMHO a productive way to do this sort of thing. As you can tell, I'm generally reluctant to add new requirements to the standard itself. For some things of course it is necessary. But if in doubt, I think that it's more agile and works better if such conventions are outside of the standard. This is in line with the history of SAMP. For instance initially the proposal was that the MType vocabulary (samp.load.votable or something) would be a formally agreed part of the standard. I think that the flexibility and success it's had so far have a lot to do with leaving these things to evolve on their own. 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/