VOEvent - Param comment

[Rob Seaman]

Al gets to the heart of the matter:

> the standard is the document which describes the standard. If the  
> schema disagrees with the documented standard, it's the schema that  
> is in the wrong.

Yes.  The VOEvent specification is at http://www.ivoa.net/Documents/ 
PR/VOE/VOEvent-20060629.html.  Any schema that successfully captures  
that specification is acceptable.  A standard specified by a schema  
is an oxymoron, just as would be a program specified by optimized,  
position independent, dynamically linked machine code, rather than  
its source.

> The VOEvent group has deliberately set out to create a standard  
> without central control, providers and consumers can appear and  
> disappear without application to a central authority, and without a  
> formal process.

I'm of two minds about the excellent and useful word "process".  The  
best uses of this word are invisible to the user.  My iMac is  
skipping through dozens or hundreds or thousands of multiprocessing  
context switches a second.  It is when a process involves a human  
that such mechanistic interpretations are least welcome.  It is  
rather embarrassing for the computer science world how many do-all,  
be-all and end-all software processes have come and gone.  In other  
communities, they look at things like Gantt and PERT charts as tools  
to achieve a purpose, not the reflection of some categorical  
imperative.  When forced to bow down to UML, I'm careful not to turn  
my back.

I'm willing to believe that XML will still be going strong in 50  
years.  It isn't so obvious that XML schemata as we currently know  
them will be.  That said, the broader notion of a schema as a data  
model certainly will.  The question for VOEvent v13.0 in 2056 will  
remain the same:  Must a formal, static data model be submitted to  
some central authority before a new type of alert can be created?

The obvious response to this is that nothing about XML schemata  
require a central authority, per se.  When the IVOA infrastructure  
and its tools mature to the point that individual authors, publishers  
and subscribers can create and later modify schemata with telepathic  
ease, I propose we revisit the question.  Two caveats:  1) I doubt  
<params> will ever be deprecated whether or not most alerts begin to  
reference included schemata - there will always be niche  
applications, and 2) It is precisely communities like VOEvent who  
have even a whiff of a hope to promulgate and popularize such flex- 
schema infrastructure and tools.  As deployed VOEvent transport  
networks like VOEventNet grow and mature, new types of messages will  
evolve to provide new functionality.  A schema definition message  
seems a possibility.  But does anybody perceive the VO or larger  
astronomical community as being mature enough right now to know what  
to do with such meta-meta-XML?  Horse to water and all that.

> Going down the creation of schema for individual message types  
> route you would not, under any circumstances, just have had the  
> adoption of VOEvent by the HTN community. The VOEvent group wants  
> to make sure that it isn't just huge projects, that can afford to  
> employ numerous dedicated programmers, that can author and consume  
> event messages.

I've already expressed my amusement to Al at the notion of huge  
astronomical software projects :-)  The success of VOEvent will be  
realized by its adoption in the field for mission critical  
applications.  GCN has been very successful by this definition.  That  
Scott has been a central player in VOEvent suggests both a bright  
future for the newer project, but also that GCN has identified a  
route to evolve past its own limitations.  The world's most perfect  
technology could be devised, but it would be useless if it is never -  
um - used.

Let's just give VOEvent a software process name, say - agile  
programming - and declare victory.

> Science is about serendipity, at least the fun exciting bits are,  
> not about central planning.

It's about both, but central planning doesn't equate to Stalinesque  
central control.

Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/voevent/attachments/20060808/b094a042/attachment-0001.html>