OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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


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]