VOEvent working draft published: version, param

[Rob Seaman]

Hi Tony,

We'll tweak the language regarding the use of IDs in VOEvent - I  
don't believe there was any disagreement over the underlying issues,  
just some entertaining repartee for the peanut gallery.

> But isn't that what xml namespaces are for? If the schema conforms  
> to a standard then you namespace the elements to that standard. If  
> you want to extend the standard you namespace the changed/new  
> elements to an extension schema so anyone using the record knows  
> which bits are usable.

I don't believe you are stating that a version attribute won't work  
as intended - after all, a typical VOEvent "metadata packet" will  
begin with a line like the following that contains an explicit version:

     <?xml version="1.0" encoding="UTF-8"?>

It sounds like versioning in XML may be a surprisingly interesting  
topic.  Perhaps we can revisit this for v1.1.  In the mean time, a  
VOEvent element will also include explicit schema usage such as:

     xsi:schemaLocation=
         "http://www.ivoa.net/xml/STC/v1.20    http://www.ivoa.net/ 
xml/STC/stc-v1.20.xsd
          http://www.ivoa.net/xml/STC/STCcoords/v1.20  http:// 
www.ivoa.net/xml/STC/STCcoords/coords-v1.20.xsd
          http://www.ivoa.net/xml/VOEvent/v1.0    http://www.ivoa.net/ 
xml/VOEvent-v1.0.xsd">

If what you are asserting is simply that we omit the version  
attribute entirely, that sounds like something that could be  
entertained, although Roy's analysis of this seems logical to me.   
But this really seems to be related to your larger suggestion of  
relying on explicit extension schemata.

> What does it mean if the record elements are namespaced to v2.0 and  
> the id says it is v2.1? It seems you are introducing a  
> contradiction into the record.

There are a thousand other ways to produce a logically inconsistent  
VOEvent document/packet.

> Creating an extension schema is significantly less effort than  
> coding up name strings and the types of values they must contain  
> with all the checking code that must accompany this. Using standard  
> xml practices means that the writers of transmitting server  
> software and receiving applications can use standard xml libraries  
> to do all the checking.
>
> I would have thought that VOEvent was the one standard which would  
> want the cleanest, quickest and most error-proof way possible for  
> encoding and interpreting its records.

The issue is precisely how to balance elegance of expression (words  
like "cleanest") with elegance of process (words like "quickest").   
There are always two roots to an exercise in the error minimization  
of a standard.  One root can be achieved simply by ensuring that  
nobody actually uses the standard.  The other minimum in the error  
curve is only reached through the compromise of a balanced standard  
that addresses the needs of all stake-holders.  VOEvent has been a  
world class exercise in building a compromise.  It is precisely the  
highly experienced "writers of transmitting server software and  
receiving applications" who I expect would be least receptive at this  
point of backpedaling toward a VOEvent specification that requires an  
explicit new extension schema be written for each instrument supported.

I've enjoyed analyzing your comments because they directly confront  
the central design conceit of VOEvent.  Many of the team have  
experience dealing with varied and detailed astronomical  
instrumentation.  It is certainly technically unassailable that the  
metadata from each new instrument represents a different flavor of  
schema - whether explicitly realized or not.  I could lull you to  
sleep with the detailed differences between NOAO instrumentation.   
Instrumentation is the Baskin Robbins of Astronomy - 31 different  
flavors for the choosing.

VOEvent, however, is not principally about characterizing  
instrumentation.  It is about characterizing events in the sky, not  
the focal plane of a telescope.  If we are to succeed at producing a  
productive format for doing so, we either need some very high powered  
tools indeed - or we need to make pragmatic compromises.  We do not  
have the time to wait for astronomical ontologies to reach maturity.   
We do not even have the time to wait for the UCD-like facility  
suggested for VOConcept.  And in particular, we do not have the time  
to wait for schemata to be developed for all possible instrumentation  
and observing modes that may generate sky transient alerts.  I fear  
that you underestimate the sheer terror of the thought of trying to  
fully characterize the behavior of even a simple astronomical  
instrument.  And each new instrument becomes more-and-more clever and  
more-and-more complex.

Providing a general purpose mechanism for grouping and typing  
keyword=value pairs using <Param> is precisely the key compromise  
that will bring VOEvent to life.  Other VO facilities will - perhaps  
- later grow up to supplement VOEvent with formally correct schema  
and ontologies and semantic expression of all types.  In the mean  
time, VOEvent will just have to settle for motivating productive  
science.

Rob Seaman
NOAO