emergency-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Minutes for SC Meeting 9-14-04
- From: Rex Brooks <rexb@starbourne.com>
- To: emergency-msg@lists.oasis-open.org
- Date: Wed, 15 Sep 2004 07:44:06 -0700
Title: Minutes for SC Meeting 9-14-04
Hi Folks,
I'm getting to this sooner
than usual. I hope to continue in that direction. As usual, please
review, and if there are changes needed please advise.
Regards,
Rex
EM-Msg SC Meeting Minutes
9-14-04
The meeting convened at
12:00 p.m. Eastern Time.
Roll:
Art Botterell
Rex Brooks
Walid Ramadan
Michelle Raymond
Rob Torchon
Approval of previous meeting's minutes was postponed pending
corrections
Old Business:
1. Much of the discussion revolved around this issue, and how possible
measures to address this issue impact the remaining items in the
agenda. The initial discussion is described in the next two
paragraphs, and then is taken up more fully after the remaining
numbered agenda items under New Business because several ideas were
brought up in regard to methods for moving the implmenter's guide and
the outreach work to promote CAP adoption forward.
It was noted that there had been several specifric implementation
questions that had been sent to the cap-dev list that Art had fielded.
Art said that this had prompted him to begin thinking about how to
organize a FAQ-type document about CAP-specific questions that could
serve as an interim measure for developers.
When asked what other issues had been raised from developers or in the
personal experience of those present, Rob mentioned that he thought
that a website or web pages that make CAP implementatons visible for
other implementers to see what kind of work is being done using CAP,
would be a good idea for helping promote adoption or just to get
people thinking about how to use CAP since the specification itself
isn't designed to answer that basic question. He noted that developers
tend to see CAP as a means for a consistent data dump rather than as a
general purpose messaging format.
2. Rex asked Art if he knew which of the NPRMs was the one which
was under consideration for the its impact on the subcommittee's work,
and, short of sidetracking a discussion that seemed more promising, we
tabled discussion of this item.
3. Art briefly reviewed the current state of development of EDXL.
Pending the next round of meetings, the work is in the stage of being
readied to sent on to the TC to be taken up as a deliverable
workproduct.
This is partially due to other events which were underway
simultaneously with our SC meeting. It was mentioned that Gary was
attending such an event.
4. The topic of registries was broached in relation to a GIS-based
prioritization of EDXL messages because the rules for this kind of
prioritization can be implemented on the basis of both a pub/sub model
and XACML role-based access, through an ebXML Registry such as
Rex is exploring through the NIST ebXML Registry Pilot Program in
connection with his XML 2004 project.
New Business:
As mentioned in item 1 in Old Business, the implementer's guide
prompted most of the discussion for the meeting, which was stimulating
enough for the meeting to extend to nearly another half hour beyond
its normal length.
When Rob initially said that he was not seeing much implementation,
his observation was that developers don't have a single web
destination where they can see and collect current CAP messages, nor
see examples of how these messages are consumed and represented to
implementer's target audiences.
Art responded that, outside of DMIS, the only other destinations where
CAP messages can be gathered on a daily basis is the National Weather
Service and EDIS in California, and, as Rob noted, Contra Costa County
California, but those are county-specific and dependent on the local
warning system.
Rob and others commented that developers are not seeing a single
information, that we need to have interesting implementations that
industry will notice such as (?hazmat source with CAP origination tool
-?-notes were hurried, so this project or example needs to be filled
in correctly. )
This example was given in answer to the need to show what can be done
with CAP--how to generate and send as well as receive a CAP
message.
RSS was specifically mentioned as a type of listing service that is
needed, and this correlates with EDIS.
Art added that a visual representation of data would also be useful
since we had included in the discussion how the GIS-based application
providers might be stimulated to participate through the GIS SC and
locating incidents on maps is a easily graspable use of CAP. This was
part of his suggestion about what to include in an interim measure
while the implmenter's guide gets back on track.
Rob specifically responded to the mention of ESRI and other GIS-based
vendors, such as Galdos, as specific candidates for participation in a
web example of CAP that could use, for instance, weather feeds , and
said that when we meet in two weeks, perhaps we can contact ESRI with
this idea of a relatively inexpensive subdomain website where
specifically GIS-based CAP implementations could be showcased.
Rex mentioned that his XML 2004 presentation will show applications of
CAP within web services and that, with help from Michelle on
personalizations, will also show how registries can aid in extending
the accessibility and usefulness of CAP-related services for first
responders and the public. However, as Rex noted, that is in November
and we need to get more immediately available examples out to the
developer community.
Walid mentioned that his team at blue292 were, like many in the field,
adopting a wait and see approach, so it seems likely that providing an
easy way to demonstrate applications that both generate and receive
and respond to CAP messages will find a receptive audience.
Art's comment that this was a "chicken and egg" catch-22
type situation was apt since we need CAP implementations to stimulate
CAP implementations, and the fact remains that a significant start
needs to be made while public interest is high enough to make it
visible. On this, there was general consensus
The meeting adjourned at 12:50 p.m. Eastern Time.
--
Regards,
Rex Brooks
--
Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]