VOEvent v2.0 is ready for prime time

[Frederic V. Hessman]

On 23 Mar 2011, at 15:07, Rob Seaman wrote:

> On Mar 23, 2011, at 4:20 AM, Norman Gray wrote:
>
>>> Please respond:  Ready for RFC?    Yes ( )     No ( )
>>
>> I think it's ready for RFC as soon as the <Reference> discussion is  
>> finished
>
> That's my perception, too.
>
> We've had 5 responses to my little poll:  2 for, 2 against, 1  
> neither.  (Perhaps more than was to be expected :-)  In addition, I  
> think a neutral observer would interpret Rick's "no" as equivalent  
> to Norman's "ready for RFC after reference is done".

Indeed, that was my "no".  And as far as Norman's comments are  
concerned....

> The problem with a format/mime attribute is that (reiterating my  
> previous message) it depends on there being a boundary between  
> meaning and format which one can distinguish in any particular case,  
> but which someone else might reasonably draw elsewhere, and which  
> might be different in a different application.  I don't believe that  
> boundary is stable enough to be baked into a protocol.
>
> Doug noted that the ObsTAP list is dealing with the same problem,  
> and (from his message of 2011 March 21 19:53; I haven't been keeping  
> up with that list) they now have a format plus two levels of science  
> type, one layer of which is to be defined in the standard and the  
> other by the data provider.  This appears to end up with _three_  
> controlled vocabularies.  That's the road we're travelling down in  
> VOEvent: it doesn't seem an attractive destination to me, but is an  
> inevitable consequence of trying to pin down the meaning/format  
> boundary.
>
> So what I suggest is skipping a format/mime attribute, and instead  
> having a single @meaning attribute, the value of which is a URI  
> (which may name a SKOS vocabulary concept but need not).  This is to  
> be compared case-sensitively [1], so it's cheap to compare, and the  
> comparison can be done as a string, with no network access required  
> [2].
>
> That's probably enough.  If something is a finding chart, you  
> probably don't need to know beforehand whether it's JPEG, PNG or  
> GIF, because you can handle all of them (and if you can't, and it  
> matters that much, use the 'Accept' header).  If it's a catalogue,  
> then a client application would I imagine be able to handle a  
> SExtractor catalogue amongst others; if the provider thinks it's  
> likely to matter which one it is, then the provider can give the  
> @meaning as a SExtractor catalogue, as Rick illustrated.  Any client  
> which doesn't know what a SExtractor catalogue is, isn't going to be  
> able to use it anyway.  The same goes for Rick's  
> #SwiftByteFormatStream and 'telemetry'.  If some higher-level  
> application needs to know that #SwiftByteFormatStream is telemetry,  
> there are ways of telling it that which this spec doesn't have to  
> concern itself with.

It's a bit wierd to drop the standard MIME-ish attributtes and replace  
them just with semantics.   The solution with a format type would have  
helped those who don't want to know about semantics (i.e. look at  
"format=" and ignore "meaning=") but since VOEventicists are semantic  
savy (and the VOEvent hackers can produce a hard-wired table to  
convert semantics into MIMEish type) then - hey! - I'm good.  Off goes  
the standard.  The changes to the changes to the docs are minimal.

Rick