Params cannot carry descriptions in VOEvent 1.1

[Rob Seaman]

  Roy Williams wrote:

> Bob Denny wrote:
>>
>>    * We should ask ourselves if a <Description> and/or <Reference  
>> inside a <Param> makes sense.
>>
> Documentation is always a good thing. If the event author wants to  
> say what this Param means, we should allow them to.

XML is chatty.  Many VOEvent use cases benefit from (relative) brevity.

Better than documentation is an interface that is simple enough to be  
obvious from the context.  No technical standard will ever fully reach  
this goal, but we shouldn't simply add a feature because it "sounds  
good".  Are there proactive reasons to add <Description> and/or  
<Reference> to params?  I don't recall much clamoring for this  
previously.

Also, isn't the proper place to describe the meaning of params in the  
VOEventStream definitions hosted in (or through) the Registry?  We  
should be eager to identify reasons to push the registry work forward.

> Params are not (or should not) have the same names. If an event says  
> X=3 and also says X=4, then it does not seem to make any sense. Can  
> XML schema express that names should be unique?

Sure, by having elements tailored to the purpose.  Params are a way to  
obtain flexibility without require separate schemata for each flavor  
of packet (or contrarily without defining a VOEvent "theory of  
everything").

> (More precisely, it should be the combination of Group name and  
> Param name that is unique.)

We had discussed this previously and the normative prose specification  
can assert such, but it seems extremely unlikely that XML schema can  
impose restrictions on the combination of two elements.

> Description is natural language, so humans can know what it means,  
> like the comment string to describe a FITS keyword. The Reference  
> can be a link to further information, that allows semantic web and  
> linked data so that machines can also "understand" the meaning.

Right - these sound like Registry functions to me.  Classify the  
packet according to a stream, retrieve the description of the stream,  
not the individual packets (which shouldn't vary within a given  
stream).  This is E-R normalization 101.

> It may be more precise, but it is not the substance of the IVOA  
> standard (*). It is the natural-language document that is the  
> Recommendation, and the schema is not, rather it is considered a  
> "supplementary resource".

This is a theological discussion.  We engineers seek a normative  
standard that can be represented pragmatically as a coherent schema.   
One nice thing of having both is that the combination encourages us to  
continue to seek simplicity.  <ZenQuote/>

> One reason for this is that the schema may not be able to express  
> constraints that we do want, and yet also impose extra constraints  
> that we do not want. Examples: we want Param names to be unique; we  
> want the sum of probabilities to be <=1; we want AuthorIVORN to be  
> in the registry, but schema cannot handle these (can it?). On the  
> other hand, we may not be interested in the order of elements, yet  
> the schema complains when the order is not what it wants; or we may  
> want recursive elements, such as a INFO containing a INFO in  
> VOTable, yet the schema seems to have a problem with this.

XML schema are (is?) imperfect.  Perhaps we can achieve some of what  
you want with a purpose-built VOEvent validator, similar to the useful  
fitsverify program from GSFC.  Even so, VOEvent-aware applications  
(many of them) will be built on general-purpose schema-aware  
components, and will need to handle packets that are legal according  
to the schema even if the additional restrictions are not followed.

I also do not believe that all members of the WG are ready to embrace  
schema-based parsing.  The current packets are simple enough to  
interpret from first principles.  SimpleTimeSeries (and maybe  
SimpleTables) start to challenge this homebrew approach, but one could  
reasonably pattern match packets containing these complex data types  
for special handling (perhaps to /dev/null for certain short latency  
applications).

Our most complex subschema will remain STC, but if anything for v2.0  
we aspire to simplify the VOEvent realization of this.  (And orbital  
elements seem like the simplest realization of STC.)  We are loosening  
the constraints on references, but not appreciably making the syntax  
more complex.  Vocabularies basically plug into the strings we already  
have.

The chair is skeptical of making the hierarchical structure of the  
v2.0 packet more complex beyond what we've previously discussed for  
the features above.  If there are good (and pointed) arguments  
otherwise, now is the time to make them.

FITS keywords have comments.  I don't know that I've ever found one  
extremely helpful.  A FITS keyword dictionary can be very useful.  We  
need the equivalent for VOEvent.

Rob