Re: [emergency-msg] CAP Channels

[Allen Wyke <emtc@nc.rr.com>]

On Tue, 2003-08-12 at 10:35, Rex Brooks wrote:
> In WSRP we are building a Primer, which I am working on with two 
> other volunteers based on a previous effort. It will include a 
> variety of non-normative explanations for some choices the spec 
> doesn't thoroughly explain and recommendations for best practices, as 
> well as an appendix on conformance statements which implementers can 
> reference for themselves to ensure that they are in conformance.

While a slightly different approach in terms of how the message is
conveyed, this is essentially solves the same problem as the purpose of
the Implementor's Guide and Test Cases/Scenarios documents we discuss in
the EM TC Requirements Document.

> I'm not sure that is the best choice for EM-CAP at this point, since 
> it is not nearly as complex. 

I agree with the complexity statement, but is that really the question?
The only reason I ask is because I think part of the purpose of these
additional documents is to restate, re-emphasize, and re-enforce the
standards. In other words, they serve the critical role of supporting
the standard. Just my perspective though :)

> As a personal choice, for myself only, I 
> am not going to recommend anything except web services in general and 
> WSRP in particular, but that does not mean that I am in any way 
> opposed to RSS, basic web services, out of band protocols or any 
> other choice anyone else either suggests or recommends.
> 
> I must admit that since my comments yesterday I have done some 
> homework on RSS and arrived at the conclusion that what I was seeing 
> in Art's example was in fact exactly what I should have expected, 
> which has also led me to conclude that RSS will not be my own 
> particular choice of instrumentality to implement much of anything 
> aimed at the general public, and the majority of B2B, IT, and e-gov 
> agency communications because it requires a familiarity with its 
> particular format and so is not suitable to anyone who is not 
> conversant with the format before they receive it. I may change my 
> mind later if RSS becomes very widely known and implemented, but I 
> won't be adding to the general creep of special communications 
> formats, such as wikis, blogs, etc, which once their novelty has worn 
> off, will either be adopted into some larger set of such formats, 
> such as html or xhtml, IM or what you have you or will fade.

While I do not think this was the intention of what you were saying in
these statements, I think you did hit on an important item in your
comments. CAP is not just for one sector. At the same time, and I know
Art will support this, part of our charter is to have CAP in a place
where it will not be inherently limiting.

I am seeing this issue raised more and more in the SC and greater TC as
we move through the process to standardization. It should definitely be
added to the SC "issue to resolve" list (yes, I still owe Art, Rick, and
the future GIS Chair a call to discuss how to triage and manage these
issues) and discussed on future calls.

Allen

> Ciao,
> Rex
> 
> 
> 
> At 8:42 AM -0400 8/12/03, Allen Wyke wrote:
> >Great email Art - you certainly raise some very good thoughts and
> >approaches to unifying "how" CAP messages are moved around. I can
> >actually add some Blue292 comments to an approach we are using, to help
> >further an investigation into this topic.
> >
> >What we have done is created a Web Service that has 3 methods, which we
> >*think* will cover all the variations of the push and pull scenarios.
> >The methods are as follows:
> >
> >getCAPAlerts(): basically, this is passed a time/date stamp, and the
> >function returns a list of alerts with their corresponding IDs.
> >
> >getCAPAlert(): this function takes a CAP alert ID and returns the full
> >alert message.
> >
> >pushCAPAlert(): this function allows you to push a CAP alert into the
> >system.
> >
> >Using these three, partners would be able to poll the system and see
> >what new alerts have been entered, and then pull the ones they are
> >interested in. At the same time, it allows them to push alerts into our
> >system. We, of course, can do the reverse with a system that has the
> >same interface - you just give us the URI to the Web Service and specify
> >the authentication method (HTTP Basic right now) that needs to be used.
> >
> >Anyway, its a stab at accomplishing a similar thing, but in the 
> >world of Web Services.
> >
> >From a standards perspective, and probably the best way to approach this
> >question of "how", we should take these two examples and any other ideas
> >the group has and lay out how we want to deal with them. For instance,
> >should we standardize on this too - as in actually put in the CAP
> >standard document? Or, should we just create an implementor's note 
> >(I think Eliot
> >suggested this at one point) to help avoid confusion for implementors -
> >something like a "CAP for Web Services" or "CAP for RSS"? Or, is 
> >there another, better idea? Rex, maybe you can chime in and comment 
> >on things you have seen within other OASIS TCs.
> >
> >I agree with your comment that we should not preclude or limit
> >implementations, so we need to keep an open mind about the various
> >methods - I am sure there is more than one. At the same time, it 
> >would probably be to our advantage to pick
> >2 or 3 approaches as a starting place to facilitate a
> >conversation on how we should handle. We definitely want to not limit
> >adoption, and having some guidance out there for implementations will
> >help achieve that goal....as long as we do not try to force it on
> >people.
> >
> >Thoughts?
> >
> >On Mon, 2003-08-11 at 16:58, Art Botterell wrote:
> >>  Friends -
> >>
> >>  Until now most of our work has focused on the CAP alert message
> >>  format itself.  But building a demonstration CAP 0.9 source has led
> >>  me to experiment with an idea developed by Robert Bunge and Eliot
> >>  Christian about one way to move CAP messages around.
> >>
> >>  Many CAP transmissions will occur in "push" mode, of course...
> >>  possibly using SOAP messaging over the Internet, or perhaps some sort
> >>  of data broadcast.  But sometimes a provider of CAP traffic may want
> >>  simply to post all its current messages on a web server... to enable
> >>  catch-up by a client that's just been turned on, for example... or to
> >>  support polling clients behind firewalls and/or with dynamic network
> >>  addresses (both of which make push more difficult)... or just to
> >>  avoid the costs of creating and maintaining  explicit subscription
> >>  records for a push service.
> >>
> >>  In such arrangements a list of current messages must be visible to
> >>  the clients.  In early prototypes we posted a simple text list of
> >>  filenames... basically just a directory listing.  Later experimenters
> >>  used an RSS file as an index to the current messages... but RSS was
> >>  designed with HTML content in mind and doesn't strike me as an
> >>  entirely comfortable fit here (although my mind remains open about
> >>  that).
> >>
> >>  So what I'm testing now (see
> >>  <http://www.edis.ca.gov/cap_0.9/index.xml>) is an RSS-like index file
> >>  customized for indexing operational XML messages.  A client can
> >>  retrieve this "channel" index and determine which messages, if any,
> >>  are a) new to that client, and b) not yet expired.  Then it can
> >>  retrieve those messages for further evaluation and use.
> >>
> >>  A few random notes about this arrangement:
> >>
> >>  * An unlimited number of sources and devices could expose some or all
> >>  of their current state in the form of channels, either to the general
> >>  public or (perhaps using HTTPS with authentication) to a restricted
> >>  community of viewers.
> >>
> >>  * For security and to reduce local network traffic some sources might
> >>  choose to publish their channels via off-site servers (as California
> >>  does for EDIS.)
> >>
> >>  * The channel index can reference messages from other servers and
> >>  sources, so a specialized channel could link to selected messages
> >>  from one or several sources... e.g., as a channel of messages
> >>  targeted to a particular region, or of a particular type.  (RSS is
> >>  used that way frequently to aggregate Web content according to some
> >>  particular editorial principal.)
> >>
> >>  * The <item> element includes the source and identifier of the
> >>  message, which together  form a unique ID for that message (at least
> >>  in the case of CAP)... so a client looking at multiple channels could
> >>  resolve any duplications it encountered.
> >>
> >>  * The <item> includes a <format> element populated with the default
> >>  namespace for the target document... so a channel could expose
> >>  multiple types of XML messages, not just CAP alerts.  (Of course, a
> >>  specialized channel client could filter out all but a particular
> >>  format.)
> >>
> >>  * An <item> can refer to another <channel>, so a "channel of
> >  > channels" might provide a basic means of discovering data sources.
> >>  (Of course, "recursive" channel clients would want to implement loop
> >>  detection, just in case.)
> >>
> >>  Again, I want to stress that the channel concept doesn't preclude any
> >>  other dissemination options or architectures... but for simple
> >>  implementations it may be a convenient and flexible approach.
> >>
> >>  Your thoughts?
> >>
> >>  - Art
> >>
> >>
> >>
> >>  ---------------------------------------------------------------------
> >>  To unsubscribe, e-mail: emergency-msg-unsubscribe@lists.oasis-open.org
> >>  For additional commands, e-mail: emergency-msg-help@lists.oasis-open.org
> >--
> >R. Allen Wyke
> >Chair, Emergency Management TC
> >emtc@nc.rr.com
> >http://www.oasis-open.org/committees/emergency
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: emergency-msg-unsubscribe@lists.oasis-open.org
> >For additional commands, e-mail: emergency-msg-help@lists.oasis-open.org
-- 
R. Allen Wyke
Chair, Emergency Management TC
emtc@nc.rr.com
http://www.oasis-open.org/committees/emergency