Params cannot carry descriptions in VOEvent 1.1

[Roy Williams]

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.
>
>     * What happens if you have 100 <Param>s with the same name but
>       different <Description>?
>
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?

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

>     * What would the <Description> elements be used for? And what's
>       the use case for a <Reference> on something as elementary as a
>       <Param>? I don't know the answers, but the questions should be
>       asked.
>

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.
>
>     * This issue is a perfect example of why a schema is a more
>       precise/rigorous way  to state the spec, combined with
>       explanatory amplification only where needed.
>
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".

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.

Having said this, I really appreciate your work with the VOEvent schema, 
I think it is a very valuable contribution to the VOEvent group. We 
should, to the greatest possible extent, make a 2.0 schema that enforces 
the definition contained in the standards document.

Roy


(*) http://www.ivoa.net/Documents/DocStd/
"The Document Coordinator maintains a repository of supplementary 
resources, such as XML schema, ... Such additional items are considered 
part of the implementation but not part of the standard itself. "

-- 

California Institute of Technology
626 395 3670