x-samp namespace suggestion

[Laurent Bourgès]

Thanks for your prompt answer; here are my comments in the text:

2011/9/29 Mark Taylor <m.b.taylor at bristol.ac.uk>:
>>
>> 2011/9/27 Mark Taylor <m.b.taylor at bristol.ac.uk>:
>> > 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