MType list

[Tom McGlynn]

The documentation of the MTypes has several potential drivers.  We may 
want to:

1. provide a location where the definitions of standard messages are defined
2. make it easy for users of SAMP to find these messages
3. identify which software recognizes or transmits certain messages
4. make it easy for developers to define and publish descriptions of new 
messages

The PLASTIC and SAMP effort has been different from some of the other 
NVO efforts in that it has run as a bottom-up development and I think it 
has been very successful.  I think an approach which strongly supports 
individual teams and small groups trying out and publishing new messages 
is very desirable to keep SAMP development active.  Using the standard 
IVOA documents approach -- even for notes -- seems much more top down.  
Perhaps we could have a Twiki static pages that describe system and 
highly standardized messages and open pages that allow any developer to 
add their own suggested messages.  This could also include entries from 
application developers noting which messages applications recognize.  
Regardless, I think the SAMP documentation should be at the IVOA not 
some external site.   Allowing a simpler URL like samp.ivoa.net or 
ivoa.net/samp to point to it would certainly make it easier to find.  
Snapshots of the Twiki could be preserved and reformatted (a la Doug's 
suggestion) to create periodic notes, but I'm less pessimistic than Mark 
about using Twiki's for long-term data preservation so I'm not convinced 
that's necessary -- the equivalent in this scheme would be a periodic 
review of the site to decide which messages are of sufficiently general 
interest that they are put in the static area.

    Tom


Mark Taylor wrote:
> Dear sampers,
>
> The formal RFC period for the SAMP PR is now at an end, and the 
> comments gathered look mostly quite positive.  There are a number of 
> editorial items that (which??) I will address over the next day or two 
> and issue a modified document.
>
> One point which has been brought up by three of the reviewers is the
> arrangement for documenting the list of non-administrative MTypes, 
> discussed in section 5.3.  This section is deliberately vague about 
> where this list is kept, in order to allow flexibility about how/where 
> MTypes are defined, and not to tie it to the SAMP document itself.  At 
> present, the list of MTypes is on the not-particularly-easy-to-find 
> wiki page at:
>
>    http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/SampMTypes
>
> In practice, the only way that developers are likely to find this
> is by asking somebody who already knows where it is, which I admit
> is not very satisfactory.
>
> Possible responses to this reviewers' comment could be:
>
>   a) we don't yet have a settled idea of how/where these MTypes will be
>      kept; therefore insist on leaving it vague in the text
>
>   b) add a reference in the text to the wiki page as the current MType
>      repository, with a note that in future some other URL or
>      arrangement may be used (wiki pages are typically not stable
>      enough to serve as long-term resources)
>
>   c) agree to issue an IVOA Note containing the existing list of MTypes,
>      and fix the text to refer to this as something which will soon be
>      available
>
>   d) agree to issue an IVOA Recommendation Track document along the
>      lines of the UCD1+ Controlled Vocabulary document, as suggested
>      by Jesus Salgado, and fix the text to refer to this as something
>      which will be available (once it's gone through the lengthy
>      recommendation process)
>
>   e) come up with a location independent of the IVOA at which this list
>      could be stored, and fix the text to reference this URL.
>      This would most likely have to be a new domain, either bought
>      direct or hosted within some third-party project (sourceforge or
>      similar, as with the plastic.sourceforge.net site).
>
>   f) something else?
>
> Of these (e) would in some ways be the best, since a SAMP web site 
> could also contain other useful content, such as short tutorial 
> introductions complementing the Standard document itself, and lists 
> of/links to applications which implement SAMP.  The PLASTIC 
> sourceforge website was quite an asset in this way.  However, this 
> option is also the most effort since it requires somebody to host a 
> web site, or to arrange one which we can use.  I asked Bruno whether 
> this sort of content would be welcome on the IVOA web site itself 
> (e.g. www.ivoa.net/samp/) but, not unreasonably, he wasn't very keen, 
> at least not without getting agreement from the IVOA Exec.
> Are there any volunteers for setting something like this up? I don't 
> mind generating some of the content, but I'm not sure about
> how to go about acquiring an independent domain name and setting up a 
> web server on it.  I note that samp.sourceforge.net is taken (Still 
> Another Math Program), and in any case the site will not mostly
> be for hosting source code so sourceforge is probably not appropriate.
>
> Failing that, I think that either (c) or, if allowed by the TCG, (a)
> would be probably the best solution.  It would be relatively easy to 
> come up with the text for an IVOA Note, and this could be issued in 
> the near future.  Updates of the Note could be issued as new MTypes 
> came into use.  A discussion area (like the one on the wiki at 
> present) would probably still be required, as a kind of "holding area" 
> for MTypes to be included in the next update of the Note.  A disadvantage
> is that, although easier than Recommendation Track documents, the 
> effort involved in issuing a Note still provides a bit of a barrier to
> making and publicisng small incremental changes in the list of known 
> MTypes, which application authors might want to do, which is easy on a 
> wiki (for related reasons I'm not keen on (d)).
> Another disadvantage is that if we decide at some time in the future
> to host the MType list on a web site or elsewhere, a SAMP document 
> which pointed at a particular IVOA Note would become out of date - 
> this is why I wanted to keep the two decoupled.
>
> Does anybody have input on how we should respond to this comment?
> It would be good to have fairly prompt replies so we can continue the
> recommendation process without too much delay.
>
> Mark
>