VOEvent working draft published: version, param

[Rob Seaman]

Tony suggests:

> Add the option of extensions into the spec, explain how they make  
> the data both interpretable and correctly typed in order to secure  
> the operation of downstream applications, BUT also allow the  
> <param> and <group> elements as now.

I'm skeptical about my ability to explain any such thing myself -  
however, a VOEvent "metadata packet" is simply an XML document.  This  
is what the specification already says about the subject:

     "XML structures other than those listed in this document should  
be used with care within a <VOEvent> element."

Aren't extension schemata therefore automatically supported?

On the broader topic of included a schema, note that the full majesty  
of STC is available for any VOEvent publisher (strictly speaking,  
creator) to craft an arbitrarily rich coordinate expression - an  
expression of formally correct temporal or spatial coordinates that  
is likely to be completely unintelligible to an unwary, which is to  
say, unprepared, subscribers.  It seems to me that the real issue is  
completely independent of either strong or weak typing or naming or  
XML schemata in general.  Rather, each VOEvent aware application has  
to encapsulate some level of comprehension of astronomical "meaning",  
whether this is called semantics or ontology or "knowledge of the  
problem domain".  I really doubt that the world's best schema (and  
I'm a strong supporter of STC) will resolve this issue.

Bottom line is that VOEvent is only of value if issuers of events  
adopt the standard and if robotic observatories are willing to  
automatically commit their expensive assets to the resulting alerts.

Rob Seaman