features for VOEvent v2.0

[Alasdair Allan]

Ballot follows with an additional "what are you talking about?" column added for clarity.

1) VOEvent v2.0:        (X) yes  ( ) no  ( ) don't care
	1a) called v1.2:(X) yes  ( ) no  ( ) don't care
2) time-series:         ( ) yes  (X) no  ( ) don't care
3) simple tables:       ( ) yes  (X) no  ( ) don't care
4) orbital elements:    (X) yes  ( ) no  ( ) don't care
	4a) ephemerides:(X) yes  ( ) no  ( ) don't care
5) <reference> typing:  ( ) yes  ( ) no  ( ) don't care (X) what are you talking about?
6) <param> typing:      (X) yes  ( ) no  ( ) don't care
7) non-empty params:    ( ) yes  (X) no  ( ) don't care
	7a) references: ( ) yes  (X) no  ( ) don't care
	7b) descripts:  ( ) yes  (X) no  ( ) don't care
	7c) multi-line: ( ) yes  ( ) no  ( ) don't care (X) what are you talking about?
8) physical inferences  (X) yes  ( ) no  ( ) don't care
9) simple STC:          ( ) yes  ( ) no  ( ) don't care (X) what are you talking about?
10) robust schema:      (X) yes  ( ) no  ( ) don't care
11) Stream template:    ( ) yes  ( ) no  (X) don't care

See below for expansion on these point...

> On receipt of this email, respond to these yes/no assertions - to voevent at ivoa.net, NOT me:
> 
> 1) A VOEvent v2.0 is needed, backwards compatible with v1.1

Yes.

> 	1a) therefore it actually should be called v1.2

Probably.

> 2) V2.0 should provide support for simple time-series.

No.

> 3) V2.0 should provide generalized support for simple tables.

No.

> V2.0 should provide support for:
> 
> 4) Orbital elements ("element" here does not necessarily imply expression as XML elements)
> 	4a) contingent on this, ephemerides

Yes. So long as this is in <WhereWhen>.

> 5) more generalized typing of <References>

You'll have to define that, my understanding is that a Reference tag can take any URI. How much more general can you get? To quote the specification;

A <Reference> element has three attributes:

3.9.1 uri — The identifier of another document.

3.9.2 type — The type of the document. Allowed values are "voevent", to reference a previously issued VOEvent packet (in whole or in part); "url", for a MIME-typed URL; "rtml", to refer to an RTML [15] document (typically the one used to drive the telescope that made the observation(s) resulting in the event), or — "ivorn", to refer to IVO resources. The default value is "url".

3.9.3 name — A short, optional name to be used in descriptive text.

So provisionally, no, because I have no idea what you're talking about?

> 6) data-types for <Params>

What would this contain? Do you mean "float", "int" that sort of thing? If so, sure I suppose so, so long as it's optional. This is really only necessary for parsing the VOEvent documents with strictly typed languages. Dynamically typed languages can just handle things.

> 7) <Params> as non-empty elements containing:
> 	7a) <References>

No.

> 	7b) <Descriptions>

No.

> 	7c) multi-line string values

Eh? A <Param> has a value. There is nothing to stop this being a really long string?

> 8) physical statistical measures (in addition to generic probabilities) for inferences in <Why>

Yes.

> 9) simplified expression of STC data-model compliant concepts

Eh?

> 10) a robust schema

Adopt whatever Bob Denny suggests.

> 11) the v2.0 schema functioning as template definitions for VOEventStreams, suitable for resource discovery in the VO Registry

That's surely up to the Registry WG? I don't see what the discussion of VOEventStreams has to do with the VOEvent group to be honest, it's a representation of a type of VOEvent service in the Registry.

Al.