EM TC Notifications Subcommittee 07-08-03 Meeting Minutes

[CSubatch@eteam.com]

Note - there will be no teleconference next week due to the DMI-S and EM TC face-to-face meetings scheduled in the Washington D.C./Virginia area.  Hope to see you all there.

EM TC Notification, Messages and Methods Subcommittee
July 8, 2003 Meeting Minutes

Attendees:
Art Botterell
Cathy M Subatch
Gary Ham
Jerry Weltman
Walid Ramadan
Eliot Christian
Ory Washenbrot
Jason Gilliam
Brian Pattison
David Hall
Tom Merckel (Observer, ComCARE)
Doug Nebert (Observer, Federal Geographic Data Committee)

Note from the GIS SC
Prior to the Notification SC meeting the GIS SC reviewed Eliot Christian's work on a GML mapping of CAP messages.  As a result of this discussion, that group recommended that the format for the CAP <polygon> element be adjusted to provide that the string of coordinates should end with a pair identical to the initial pair, thus unambiguously indicating closure of the polygon.  This is the practice in GML.

Agenda
Two issues plan to discuss:
1.  ICS Forms project
2.  Brian's thoughts on how we handle binaries in CAP message

Meeting Notes
Gary – at next week's DMI-S meeting (scheduled for the morning of Tuesday, July 15th at the Battelle facility in Stafford, VA) they will show the ability to retrieve a CAP formatted incident message in the CAP format.  Is being worked on right now and may be ready for next week.

Jerry – what is next step for CAP?
§        Art – still picking up some issues such as how do we represent polygons raised in this morning's GIS calls.  Also getting some feedback from the public,                 though mostly have gotten congratulatory notes
§        Formally, the SC votes out to full committee, then the TC decides if it becomes a committee recommendation via a committee vote.  The next step is                 advancing to OASIS Standard level – must submit showing from three member organizations and that they are using the proposed standard (it was noted         that OASIS is explicitly vague on its definition of what "using" is)
§        Next substantive step is to start generate and document reference implementation
§        Gary Ham – three sponsor organizations must be part of OASIS.  There is
1.        DMI-S
2.        ComCARE (though they still need to officially join OASIS)
3.        Maybe EDIS can be counted.  Or the Partnership for Public Warning

§        Voting at OASIS standard level – in order to become an OASIS level document a certain percentage of the membership must vote a "Yah" and not less than a certain percentage can vote "no."  It's important that we get enough of membership to care enough to vote.  Should be noted that we are not actually required to take to full OASIS standard and some things may.
o        CAPWin may be able to help with outreach. Many want to play in federal arena
o        Eliot – let's start working issue and contacting people to get awareness up.
§        Art – in addition to formal standards document, will need a tutorial pamphlet to introduce this.  Next step will be education and reaching out to various communities of interest to build awareness.
§        Tom - can send to National Institution of Justice as a clearinghouse
§        Brian – can leave as committee recommendation until we get groundswell – attempt to turn into a standard before groundswell than see apathy.  So can get recommendation out there so people can play with it.
o        Eliot – longer we wait the more chance other options may be 
o        Need to let Executive Committee know so they can start with educational awareness
§        Eliot – stay away from the Amber Alert stuff.  They are going to be out in public space very strong.  Don't want to appear competitive.  Need to show implementation showing amber alert. 
§        Brian wants product that can generate that – using CAP standard.   Should be available shortly.
§        Tom - IEEE - .2 not flushed out yet.  (Missed This is a real standard.  EMS public health should be covered by us. Lot of synchronization to be done or everyone will have a different standard.
§        Tom - Looking to see how CAP to be tied into transportation also.
§        Recommendation to DHS likely to reach fruition anytime soon.

ICS Forms Status
§        Art – Thanks to David for first cut of requirements.
§        We are working with something that is pseudo standardized.  Conversion of form standard to standard we are talking about.
§        Look at real data structure inside the fields is not as simple as it looks.  Some fields have multiple sublevels.
§        Art – David had described Form 201.  This is a fairly simple report document and 202 is complex
§        Dave – at last face-to-face meeting, group decided to pick only six or seven to focus on.  Picked two to define requirements to see if acceptable to group.  201 and 202 taken together make up incident action plan.
§        Art – maybe 201 was a worthwhile project.  Based on how that goes may follow up with 202 or larger ones. Is there bite size chunks to take on?
o        Dave need to do in (ICS XML standard) – may be better to float with one form better than multiple.
§        Art - do people (implementation end) see this as worthwhile project? Consensus is yes.
o        Impetus came from expectation that NIMS was going to be ICS based so this seemed like a good place to go.  Does having an interface to ICS forms – or a digital form of ICS forms – make sense?
o        Gary – two schools of thought.  Can look at forms on how people organize information on the forms, not in databases.  People are used to using them in that fashion.   On the other hand can be concerned about how data is structured in database.  May be that a number of systems organization presentation and reports based on ICS forms look similar but data structure would be different.  Since dealing with interface information can be interested in human interface so will go with pure forms.  We may be interested in data structure for transporting between databases.
o        Art – there is a middle tier between the user interface and database issues.  As long as there is mapping of data items between one and another, conversion can occur at any point.  But the messages that move around the wires in heterogeneous environment does it make sense to move around in the ICS forms structure or another way that is useful.  Gary –Need standards in both ways.  Not mutually exclusive.  Clear that this is the right data, proven over time.  Is it organized for computational use and for knowledge management?
o        Art – no consensus to internal structure because every implementer will have their own.  Base on UI because there is consensus.
§        Art – is it sense of subcommittee to proceed to do definition of at least ICS 201?  At least we need to draft this.  Then we can make decision to go after others.  201 good starting point – microcosm.  Gives us a point to start building a data dictionary that will be consistent through ICS set. Can use same data dictionary to support CAP. 
o        Gary – will that also support the IEEE data dictionary
o        Tom – I can take a look at that and get back to the group
o        David – how many other efforts are we going to attempt to correlate to?
§        Art - How to we define correlation?  Semantic congruence is most important thing.
§        Tom – boil down to least common denominators.  Eventually all these dictionaries will come together and form base library for DHS.

[At this point Cathy Subatch had to leave the call and the quality of the recordkeeping deteriorated accordingly.]

§        Art volunteered to draft requirements and scenarios for the ICS-201 project, and David Hall agreed to start analyzing the form and drawing a document object model.

The final topic of discussion was how to associate ancillary files, especially binaries such as images or audio files, with the basic CAP message.

·        Brian pointed out that, when such files are delivered separately from the message itself, e.g., by URI reference to a file on a web server, it's possible that the attachment might be changed after the CAP message was issued.   Gary Ham reported that Battelle also has encountered this potential problem within DMI-Services.
·        Art suggested that providing the messages separately helps keep the messages small and that not all networks and not all clients will be able to access or use such attachments.
·        It was suggested that by including a digital digest for a detached asset in the message it would be possible to verify that the asset referenced was the same as the asset received.
·        If an asset was included with the message, it could be:
o        Base-64 encoded and included within the message body
o        Attached using SOAP-with-Attachments and referenced using a URI
·        The relative merits of these three approaches (detached w. digest, inline and attached using SwA) and the question of whether one or several should be supported were discussed but no conclusion was reached so the question was tabled for further discussion in email.

Next Meeting

Due to the DMI-S API and the EM TC Face to face meetings, there will be no meeting next week.  Next call will be Tuesday, July  22nd at 9:30 am PDT/12:30pm EDT

Dial in: 1.800.453.7412
Access code: 604776







Cathy M. Subatch
E Team Inc.
818.932.0660 x248
310.770.6885 (mobile)
csubatch@eteam.com