Summary: features for VOEvent v2.0

[Rob Seaman]

> How is a v1.1 packet compliant with a prose specification for a  
> later version? Every entity in the packet retains its original  
> structure in the later version?

<SimpleTimeSeries> and/or <SimpleTables> are new elements.  They will  
be optional.

Ephemerides and orbital elements are conforming STC - the intent is,  
if anything, to simplify the implementation of <ObsDataLocation> in  
the v2.0 VOEvent schema.  (The floor is open for discussion regarding  
the details.)

The <Reference> and <Param> typing will be additional (but optional)  
attributes and/or looser constraints on the values of those attributes.

<Params> are currently empty elements - permitting them to have values  
(should this be the consensus) will not deprecate the currently empty  
expressions.

Any change to <Inferences> under <Why> (for v2.0, anyway) will be  
restricted to adding attributes and/or elements or loosening previous  
restrictions.  Any such changes will be modest in scope.

Finally, I do not believe that we need to retain compliance with  
packets that nobody ever has or ever will create.  Aside from  
simplifying our usage of STC, all changes will be relaxing prior  
restrictions.  In some Platonic world, requiring more stringent  
limitations on <ObsDataLocation> (however achieved) would be deemed to  
blast backwards compatibility into smithereens.  This is not that world.

I presume that projects parsing packets using Eli Whitney era  
technology do not care about the change to the explicit version in the  
packet header.

Rob