VOEvent session

[Rob Seaman]

So consider Roy's example:

> My favorite data model is the complex number,

(I was under the impression your favorite was "the banana".)

> with a data model of Real and Imaginary components. Here are some representations of the number z=1+2i. The advantage of (1) is automated code binding and document validation. The advantage of (2) is flexibility and encoding validity in a non-XML layer. The advantage of (3) is simplicity and conciseness.
> 
> (1) "Pure" XML
> <complex name="z">
>  <real>1</real>
>  <imag>2</imag>
> </complex>
> 
> (2) Impure XML a la VOTable, VOEvent
> <Group name="z" type="complex">
>  <Param name="zr" utype="complex.real" value="1"/>
>  <Param name="zi" utype="complex.imag" value="2"/>
> </Group>

These are isomorphic as written - not surprising since they are both XML.  What Schema adds to XML is a way to require a certain internal structure.  #1 can require (as a complex number does) that both <real> and <imag> be present.  In the case of #2 a <Group> may require zero, one, or more <Params>, but can't specify that both these utypes must be represented.  XML is not the same as "XML Schema".  These are both pure XML.

> (3) JSON
> {"z": {"zr":1}, {"zi":2}}

If we were in a position at this late date to consider non-XML representations, we might be well advised to evaluate many other possible options in addition.  It seems clear that IVOA is moving away from what Doug calls "complex XML with schema verification".  My question, I guess, is whether IVOA deprecates "complex XML" or rather "schema verification" or rather the combination.

If the argument is that VOEvent should anticipate IVOA trends - and that the trend is to move to a simple baseline schema-verified flavor of XML - and further that complexity is brought back in through a few hundred utypes mapping to a few dozen data models - well, then, it isn't clear what value the schema is at all.  Also, this seems to suggest that all IVOA XML will eventually devolve to VOTables or some other common container for utypes.  (Me?  I'm thinking all snarks are boojums and all VOTables may turn out to be FITS bintables.)

For one thing, doesn't this mean that the STC schema will itself turn into the equivalent of a group of params with utypes such that as Doug says, "the [STC] data model itself...has to be understood...either by human or by code"?

I know where I think the "natural resonance" lies for a VOEvent packet (whether XML or anything else), and it certainly isn't a "point [before] which relational or more explicitly hierarchical techniques are required" - which is to say a flat table of three columns: name, utype, value.

For one thing, omitting all these technology options from discussion, the packet does "want" to have a basic structure similar to <Who>, <What>, <Where> + <When>, <How>, <Why> and a citations mechanism.  It does not want to have utypes from a half dozen data models mixed up together in one pair of {} braces like enzymes in a cell membrane.

Many VOEvent packets represent a measurement of some sort.  The independent variables - suitable for targeting follow-up observations - go in <WhereWhen>, whether STC or something else.  The dependent variables - clues at the scene of the crime - go in <What>.  This latter corresponds most closely to what has been referred to as a payload - data, perhaps referencing an external data model via utypes.

On the other hand, if the nature of a data model is something that "has to be understood by a human or (human conceived) code", isn't the proof of the concept precisely STC?  STC is the most "astronomical" of IVOA data models (astronomical as opposed to astrophysical).  Those of us with an astronomy background (may) grok the need for such a thing.  Those with a computer science background, (perhaps) not so much.  Where is the balance point for STC in the schema/utype tug of war?  This discussion has focused on <What>.  Is it rather <WhereWhen> we should be debating?

Rob