Bringing VOEvent v2.0 home to roost

[Mike Fitzpatrick]

    I've had a first pass through the document and I'm generally much
happier and willing to implement the final form.  A few specific
comments follow.

Cheers,
-Mike




General Comments:

    - Reference citations almost all wrong, references > 4 are off by one
        (e.g. [21] should be [20] and so on).

    - Would like to see a simplified view of the schema as in Sec 7 of
        the VOTable rec.  When implementing, there are a lot of words to
        sort through to find element hierarchies, attributes etc.



Sec 1: Introduction

  2nd to last paragraph:

  "The results of astronomical observations using real telescopes must
  be expressed using the IVOA VOEvent standard, be recorded and
  transmitted via registries and ....."

        Isn't recording and transmitting a repository/transport
responsibility,
        certainly not registries?


  "Each event that survives rigorous filtering can then be passed to
  other real (or possibly virtual) telescopes, for instance via XMPP,
  ASCOM, dc3.com, or some other transport protocol, ......"

        Need references if these are meant to be actual transports,
otherwise
        suggest more general language about passing events on through the
        e.g. "VOEvent transport network" or somesuch.


Sec 2.1: Publishing VOEvent Packets

  "In addition to Publisher and Subscriber, the following roles define..."

        Suggest you open with just "The following roles define ...."  The
        concepts of Publisher/Subscriber haven't been introduced yet.

Sec 2.2: VO Identifiers (IVORNs) and Publishers

  "... meaning that a registry exists that can resolve that identifier to
   the full VOEvent packet."

        Suggest "that a mechanism exists ...." instead.  Registries won't
        resolve the identifier completely, only turn the base part of of
        id to some sort of (SEAP?) service that returns an event doc for
        the local_ID part of the identifier.

        The whole issue of how this mechanism should work, exactly what
        gets put into the Registry for service discovery, metadata, etc is
        still very vague.  I assume docs describing those details are in
        the works?  The VOEventStream WD should also be referenced, it has
        some of the info needed to define the "principal schemata" listed.

Sec 2.3:  Authentication and Authorization

  "....These questions are addressed elsewhere."

        Where exactly?  As used generally w/in IVOA or specifically w/in
        VOEvent, i.e. with SSO certs be passed to authorize my event packet
        if I'm a Publisher or will you lookup my <Who> to see if I'm a
        good guy?

Sec 2.4.2: VOEventServer in the VO Registry

  "Three kinds of capability that we can mention are subscription, formal
   query, and informal query."

        No mention is made of what constitutes and "informal query".


Sec 3.:  VOEvent Semantics

  "A VOEvent element may contain at most one of each of the following
   optional sub-elements: ...."

        A strict interpretation would suggest a packet such as

          <VOEvent>
            <Description>Bright star left of the moon at
                Mar 7 15:31:46MST as seen from my backyard</DESCRIPTION>
          </VOEvent>

        is a compliant packet, although not terribly useful.  I think
        most people expect event packets to be either the simple reference/
        citation type, or "complete" packets with the whole Who/What/....
        structure.  The line break in the grouping of elements suggests
        this as well, but is some more formal language needed to prevent the
        above sort of abuse?

Sec 3.1.2 role -- .....

  "The optional 'role' attribute accepts several possible values, including
   these:"

        Does this mean the value of the attribute is/can be several values?
        Is this a free-form value or does the list of 4 roles given comprise
        the list of acceptable values?  Is there a need for having compound
        roles?

Sec 3.3.1.5  dataType -- A string .......

        Does this need to be camelCase, I don't think that is generally used
        in other specs?

  "Allowed values are "string", "int",or "float", with the default being
   "string".

        Why can't this be the same set of primitive types allowed in a
        VOTable <PARAM>??  Do 'int' and 'float' assume 32-bit values and
        precision limits?

Sec 3.2.2  Group -- collection of related Params

  "There are rules of uniqueness Params and Groups in VOEvent:"

        "....of uniqueness for Params ...."

        Also, the 'type' attr is not requied to be unique...Are there
        examples of why this might be useful (e.g. multiple groups defining
        photometry params as distinct from the groups defining spectral
        params)?


Sec 3.3.3 <Table> -- simple tabular data

  "It should be noted that longer tables, or any table, can be linked using
a
   <Reference> element"

        How do I interpret a <Reference> link to a longer table if the
<Table>
        goes on to define <Field> and <Data> elements?  Should <Reference>
be
        exclusive to link to longer tables, seems to me to be a clearer case
        than a <Reference> meant to further document the table unless this
        can be distinguished by the uri/type attributes of the <Reference>


Sec 3.4.1  ObservationLocation

        Suggest there be a simple, declarative openeing sentence saying what
        this is meant to define, similar to <ObservatoryLocation> in the
        following section.

Sec 3.4.2  ObservatoryLocation

  "The id here indicates a specific registered observatory, other examples
   being: Keck, KPNO, JCMT, MMTO, VLA, <i>etc.</i> , ...."

        Registered where?  Does this assume 'Keck' will be a Registry
        resource giving it's position or maybe that the author's <Who>
        information will have it somehow?


Sec 3.3.3.6  dataType -- A string .......

        Again with the camelCase ....
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/voevent/attachments/20110307/98e91b68/attachment.html>