|
From: John T. <jd...@ro...> - 2006-09-13 16:07:44
|
Personally I'm not too worried about the "purity" of PLASTIC and the fact that we're using messages to indicate file format for tables, but to indicate content for spectra....if people outside the current clique start defining their own messages (which I would see as a good thing) we'll end up with a a mixed approach anyway. I'd like to make a few comments on the "user experience". We made the "load table" message explicitly specify VOTable in the message string as it seems reasonable to mandate this as the standard table interchange format. That way, each tool need only support a single format in addition to what it supports natively. I have found this to be a little restrictive when you have FITS files in MySpace that you know to be tables but cannot send directly to Topcat. However, when the new VOSpaces are ready with their ability to export data in different formats this won't be an issue. The "load table" message doesn't specify the semantic content since tables are so general. So far, I haven't encountered any usability issues here...though you can imagine a tool that requires RA&DEC failing if it's supplied with any-old-VOTable. For spectra, having the message string reflect the fact that a spectrum is being sent seems to be the right approach since spectra are more specialised animals. However, if we are going to pass in the data format as an argument we should check that most spectrum consumers will support most spectrum formats...otherwise the user is going to be frequently frustrated by "format not understood" exceptions. Are we confident that this is the case? If this is not the case, then we could still consider making the data format part of the message. The difference for the user would simply be that he won't be allowed to send the spectrum to an app that won't understand it. I'm not too worried about the proliferation of messages - provided we used a sensible naming strategy such as ivo://votech.org/[data format]/spectrum/loadFromURL then it wouldn't be too difficult to manage (and strings are really cheap). It could get a little unwieldy if a message included two or more spectrum arguments, but as our manifesto ways "do what works 90% of the time". (or if it doesn't say that it should do). I'm not necessarily advocating this approach - it means a little more programming work than that proposed by Mark - but I just want to say that we shouldn't rule it out because we're scared of inventing messages, and that picking one approach this time doesn't commit us to do it next time. Could someone with knowledge of spectra viewers confirm that "most commonly used spectra viewers will support all commonly used formats"? John Mark Taylor wrote: > Plastic Pals, > > I have documented a new proposed message for loading spectra at > > http://eurovotech.org/twiki/bin/view/VOTech/PlasticMessagesProposal > > I had discussions with various people at Strasbourg about this; > it is unlike the votable/loadFromURL and fits/image/loadFromURL > messages in that it relates to the semantic content (it's a spectrum) > rather than the data format (it's a FITS file) of the resource > at the URL. The reason for this is that there is a very wide range > of possible serializations of a spectrum/SED (FITS 1-d array, FITS > binary or ascii table, VOTable, FITS or VOTable serialisations of > DM spectral data model as described at > http://www.ivoa.net/internal/IVOA/IvoaDataModel/spec98c.pdf, ...), > trying to cope with all possibilities could lead to an explosion > in the number of messages. > > There are arguments for and against doing it this way, but on pragmatic > grounds I think this is the most workable solution. If you disagree, > feel free to continue the debate here. > > Mark > > -- ------------------------------------------------------------------------ AstroGrid/VOTech & Institute for Astronomy, Edinburgh Skype:johndavidtaylor <skype:johndavidtaylor?chat> ------------------------------------------------------------------------ |
