VOEvent working draft published: version, param

[Tony Linde]

Continued...

> > 3.1.3 version:
> >
> > Why do you need the version number of the spec? Won't that be 
> > contained in the namespace for the metadata elements?
> 
> Reason 1: Because it is simpler and easier for a parser to 
> get the version number from a specific attribute.
> Reason 2: Because there may be local updates to a version 
> that have not made it up the standards process yet.  A 
> collaboration could use their homegrown version 2.1, but it 
> all still parses with IVOA namespace version 2.0.

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.

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.

> > 3.3.1 <param>:
> >
> > ...
> 
> We have had this discussion before in the VOTable context......
> 
> Objective: We want to add flexibility to the format, so that 
> somebody can put in a datum like
> GCN_INTEN_CNTS=17467
> 
> My solution is to just put in a
> <Param name="GCN_INTEN_CNTS" value="17467"/>
>   It is simple and easy, and if the receiving software knows 
> what it means and that it should be a positive integer, then 
> we we use it. But if you don't know what it means or what to 
> do with it, it is useless.
> 
> Your solution is (I think) to make an extension schema, 
> called perhaps "gcn". In this case we could encode it as:
> <gcn:GCN_INTEN_CNTS>17467</gcn:GCN_INTEN_CNTS>

I think your solution, Roy, is neither simple nor easy but complicated and
prone to error. Using the extension schema, an application can see upfront
what standards the record conforms to and which bits it can handle; it can
pull out and use exactly the bits it understands and never even see the bits
it does not know how to handle.

Using the <param> approach, the application has to inspect every single
<param> element, extract the name strings and then compare them with some
sort of internal database of strings to see if any of the strings match
things it can understand and only then can it begin to work with the data in
the <param> element. 

But there is no guarantee that the <param> contents are what it is
expecting. A VOEvent record could contain <Param name="GCN_INTEN_CNTS"
value="fred bloggs"/> and it would be perfectly valid but would break the
software. There is no standard for mandating that the names of params have
to conform to some limited list so anyone can create anything and you WILL
end up with two groups creating the same name for different data, thereby
breaking the downstream applications. The extension solution allows two
groups to use whatever names it wants because they are distinguished by the
namespaces.

Using the extension/namespace approach, every VOEvent record can be checked
for validity instantly using standard xml libraries. The transmitting
software ought not to even emit invalid records if it is using these
libraries. Using <param>s every receiving application has to implement its
own checking of each <param> element for valid contents. 

> In this case the extension schema would encode the idea that 
> the value should be a positive integer, and it would be 
> automatically checked. 
> But I maintain that the extra effort of the extension schema 
> has little benefit over this automatic checking. I still have 
> to know the semantic meaning of the paramter and its 
> relevance in order to make use of it.

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. Using <param> elements will ensure the exact
opposite of that as a result.
 
Cheers,
Tony. 

> -----Original Message-----
> From: Roy Williams [mailto:roy at cacr.caltech.edu] 
> Sent: 23 June 2005 23:23
> To: Tony Linde
> Cc: voevent at ivoa.net
> Subject: Re: VOEvent working draft published
> ...