Madrid InterOp roundup

[Mike Fitzpatrick]

On Sun, May 25, 2014 at 7:52 AM, Rob Seaman <seaman at noao.edu> wrote:

>
> "Strong IVOA notes" sounds a lot like "registered FITS conventions".  ....
>

Not really, since the intent of a 'strong note' (naming choice aside) is to
indicate that the note has been reviewed by working groups formally to
identify possible conflicts, and has had a RFC period for people to weigh
in on it.  OTOH, it isn't constrained by the process of a full REC should
it be changed.  In the end it is really an endorsement that the note won't
cause any conflict if used right now, but it doesn't prevent the
development of a full REC in the future.


>
> > We also discussed the VOEvent Transport Protocol document which I
> circulated a couple of weeks ago: <
> http://www.ivoa.net/pipermail/voevent/2014-May/002959.html>. Although the
> consensus continues to be that moving this towards IVOA standardization is
> the ultimate goal, Mike had a number of suggestions pertaining to the most
> recent draft. We agreed, therefore, to open it up to another round of
> discussion on this mailing list.
>
> It would help to know what Mike's suggestions were.
>

The comments aren't things that couldn't be fixed in an RFC period, and
putting it back to the mailing list might ensure more people read it.  I'll
reply to John's original comment thread on the VTP draft to keep it in
context, but my comments had to do with

    - use of an IVORN in the <Origin> and <Response> elements of an ack
packet (IVORNs must be resolvable in the registry, I didn't think we would
want clients/brokers to be required to be registered for VTP to work in a
strict compliance mode)

    - the limitations of 'ack' and 'nack' as the only responses (there's no
way to indicate we want a packet to be resent due to corruption, that it
was invalid, or that the receiver rejected it as not meeting a subscription
filter, as a duplicate, etc).   We can expand the list of options without
breaking existing code while making new brokers/clients more capable.



> > This involves coordinating with data providers who might wish to publish
> time-series data
>
> This implies post facto queries from repositories.  The question for
> workflows is rather real time delivery.  The original VTP note doesn't
> dwell on transport of non-VOEvent packets, but is the thought that a VTP
> stream might interleave VOEvent, STS and other packets?
>

STS is the response you would get from an existing TimeSeries service e.g.
following a GET query for an object.  VTP specifically is for VOEvent docs.
 What we don't have is a doc that describes how Brokers and Repositories
might exchange mixed data types (e.g. a full event history, ancillary
images/STS, etc), that is something the VOEventContainer might address.
 Unless it is included as a simple table in the VOEvent doc, subscribers
aren't likely expecting an STS.  Rather, a workflow might trigger off a
VOEvent notification and then make a separate query to a TimeSeries service
to explicitly get an STS.  Of course, we don't have a rec for how to query
a TS service either.

Much still to do ....

-Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/voevent/attachments/20140525/dec237d3/attachment.html>