Summary: features for VOEvent v2.0

[Rob Seaman]

Right.  I said something similar recently (if less eloquently) and it  
seemed to generate friction so I decided to go with the "backwards  
compatibility" phrasing, if less precise.

I believe some projects continue to parse the packets as raw XML,  
rather than using schema.  The intent is that a v1.1 compliant packet  
should be compliant with the v2.0 prose specification.  The chair  
takes no position on how packets should best be parsed - but clearly  
others in the WG do :-)

The v2.0 prose, however, will be carefully vetted against a v2.0  
schema that is robust and efficient.  The obvious strategy to carry  
all this off is to keep the standard as simple as practical, including  
any streamlining of STC plumbing as well as the prudent addition of  
the advanced features of time series and/or tables and orbital  
elements/ephemerides.

It is my opinion that omitting the advanced features would in reality  
result in *more* complex packets since the same richness of semantic  
expression would have to be crammed into grouped params, a data  
structure less suitable.

Rob
---

On Apr 9, 2010, at 3:32 PM, Matthew Graham wrote:

> Hi Rob,
>
> On Apr 9, 2010, at 2:41 PM, Rob Seaman wrote:
>
>> The general goal is to retain backwards compatibility to v1.1.
>
> I'd like to ruminate on this for a moment. I'm assuming that  
> backwards compatibility here means that a VOEvent 2.0 client can  
> handle a VOEvent 1.1 packet, i.e. a client designed specifically for  
> VOEvent 2.0 will encounter no problems if presented with a VOEvent  
> 1.1 without any special provision for it (no "if version = 1.1 then"  
> statements). Now any VOEvent packet is defined according to a  
> particular version of the schema, enshrined in the namespace to  
> which the packet belongs. So the VOEvent 1.1 packet:
>
> <voe:VOEvent>...
>
> and the VOEvent 2.0 packet:
>
> <voe:VOEvent>...
>
> will have different namespace attached to the 'voe' prefix. Any  
> piece of software which makes use of the namespace - XPath and  
> XQuery, package names in generated code from the schema, etc. - will  
> therefore break when presented with a packet from a different  
> namespace, especially if it is built just from the 2.0 spec. Note  
> this is not about validating the packet against the schema, this is  
> about parsing the packet. The exact same situation exists between  
> VOSpace 1.0 and 1.1 because you are defining a versioned message  
> protocol and code written to work with one version will not  
> automatically work with the other.
> If you want your code to work with both versions of  VOEvent then  
> you will have to specifically write it to deal with VOEvent 1.1 and  
> VOEvent 2.0.
>
> 	Cheers,
>
> 	Matthew
>
>