Notifications, Method and Messages
EM TC Subcommittee
April 29 2003
Attendees:
Art Boterrell - Chair
Eliot Christian
Naseam Elkarra
Jerry Weltman
Gary Ham
Cathy M Subatch
Prior to official start of meeting, Eliot mentioned that the GIS subcommittee had just completed its first subcommittee. It committed to reviewing the OpenGIS standard for location-based services and pull out relevant pieces for CAP.
Meeting Notes:
Art opened meeting by asking how the group should proceed? Recommended start by:
- Create requirements
- Build use cases
- Create object diagrams
- Build data dictionary
- Build schema
All agreed this was the correct approach. Issue is that there are two to three projects on the subcommittee's plate. Discussion regarding data dictionary:
Should we use unified data dictionary? --> Take forms and derive object diagrams.
- Gary - Input should not be form-centric. Lots of hierarchical data structures flatly laid out. Need to do modeling task in advance
- Eliot - pull out the elements
- Art - Inherent structures of forms worth taking seriously. The closer we can stick to structure, closer we can stay to the user base. Not limited by the physicality of paper.
- Eliot - First record as general data element that can be used in other structures.
When group is discussing "Forms" they are referring to ICS and CAP forms (CAP forms are moved more toward XMLizing)
Art: has posted a group of documents on the subcommittee page (to view all the documents you must click on the "view" button. The CAP section includes the original documents that the CAP working group began with. This SC should mark this up and make some version of it its own.
- Jerry: keeps hearing referencd to ICS forms - who is using?
- Gary: also who is sharing. Need to concentrate on forms being used in cross sharing environment first.
- Jerry: XMLize information on the ICS forms - what software system would use? what are those systems doing now? Why aren't they already in XML format?
- Eliot: what is the real focus on interoperability?
- Gary: Need use cases
- Art: Most software vendors implementations are close to ICS forms but are proprietary. Look like ICS for user familiarity. We can document some existing processes
Incident Notification
Gary gave some insight into the Incident Notification
- Have an XML structure that gives you core incident information and allows you to attach information.
- Had seen first exposure and it has changed a lot.
- It shows what "Get Incident" is but is it unique enought for unique recommendations?
- An abbreviated report of incident status.
- Maybe we can take the data structure of Get Incident and wrap in notification wrapper.
- Based on real data that does exist
Naming Conventions
- Art reviewed copy of 11170 and it does not provide naming conventions,provides meta for building naming conventions
- Gary: naming conventions most effective in understanding are usually too long for programming and bandwidth requirements. Plus usually unique - Dept of Justice name for "facility" would only suffice for "correctional facility"
- Eliot: names in CAP are good
Action Items:
- Review old CAP requirements draft and comment (goal is to boil down to new requirements document for subcommittee)
- Take a cut at requirements statement for ICS (Art)
- Get additional information to the subcommittee about Incident Notification - circulate summary (Gary)
Next Meeting
Tuesday, May 6th at 9:30 (TC meeting at 10:00)
Cathy M. Subatch
E Team Inc.
818.932.0660 x248
310.770.6885 (mobile)
csubatch@eteam.com