Minutes of Today's Meeting

EM-Msg SC Meeting Minutes 9-28-04

The meeting convened at 12:00 p.m. Eastern Time.

Roll:
Art Botterell
Rex Brooks
Jack Fox
Gary Ham
Jeff Kyser
Michelle Raymond
Carl Reed

Old Business:

1. Much of the discussion revolved around the issue of the Implementer's Guide, and how best to conduct this work. However, because we arrived at a motion and decision, that decision merits first mention. It was decided without dissent in a unanimous vote to table the issue and recommend to the full committee that work on the Implementer's Guide be suspended until either: A-sufficient matrial is amassed to justify assembling a single document; or, B- specific user requirements for this work are identified.

The general consensus of the disucussion which led up to this motion put forth by Art and seconded by Elysa, was that we should consider maintaining some kind of regularly updated FAQ-like document taken from the issues brought to the developer's list or to the attention of the committee or subcommitee, but we did not come any agreement on just exactly what that document ought to be. However, this was clearly identified as an agenda item for our next meeting. .

Because we have not discussed this more fully, I will attempt to capture the main points of the discussion, subject to the proviso that this is limited to one individual's ability to take notes during a lively discourse.

Discussion carried over from the GIS Submittee meeting which preceded this meeting, with Gary explaining that there were major EOC, Emergency Operations Center, smiulation exercises conducted the previous day, September 27, 2004 that included simulating a Madrid Train attack analog on the Washington D.C. Metropolitan Transit System.

This was cogent because it sets the stage against which our work is proceeding, i.e., an active, energetic and ongoing effort to learn how to coordinate EM systems from the national to the local level. To some extent this discussion was an extension of exploring the notion of seeking to implement a public website where CAP messages based on GIS coordinate reference systems could be pulled by implementer's who could also see what kinds of implementations had been developed through maintenance of samples of those applications on the site

Elysa and Jeff made the point that the main context in which CAP is being implemented is in the usrs or consumers of CAP messages, but, as discussion confirmed, we need to be concerned with both producers and consumers of CAP.

Art stated that his experience in these last recent months and over the longer period of time he has been working with this overall issue that implementers, or would-be implementers usually have questions in regard to transport-specific topics. Furthermore, as it has developed so far, there are two main ways in which the use of CAP has been implemented: the web-services API method exemplified by DMIS and the system it provides, and the REST or RESTful indexed list approach exemplified by the weather service and EDIS.

Gary pointed out that DMIS has user guide material on their website for reference by its users, which could serve as a model if that is what we eventually choose to do. Gary also mentioned that DMIS had just finished compiling use case-based requirements and that he would post them to the list and/or the documents repository of the TC. These materials would be certainly be useful in working on an Implementer's Guide when, and/or if that is demanded.

Elysa suggested that building a scenario or use case for the XML 2004 interop demo would be a good way to develop implementation issues that would fall out of the work we do to produce the demo. As a corrolary Gary noted that this might bring up some specific issues related to optional fields in CAP, which he said his experience showed were sometimes not implemented under such deadlines as we will be facing.

There was also some specific discussion, which led to the motion which passed tabling the issue, about the issue of difficulty with free text in CAP fields, especially these optional fields. As the discussion around that started to drill down into specific language we might use in a recommendation in an Implementer's Guide, Art pointed out that if developers are having problems with this, or if problems or concerns are rising out of this, we should focus our attention on addressing it in the next version(s) of the spec as opposed to an Implementer's Guide which we have not really seen a great need of or demand for at this point.

There were, of course, other issues which were brought up that I have not tried to capture, but it seems to be boiled down into the question posed by Michelle, "Do we write specifications or recommendations?" It was agreed, as Elysa observed, that our limited time is best spent on the specification.

The meeting adjourned at 12:45 p.m. Eastern Time.

--
As always, please feel free to comment with corrections.

Regards,

emergency-msg message