EM TC: Year in Review and Next Steps

[R. Allen Wyke <emergency-tc@earthlink.net>]

It was a little over 1 year ago - on February 11, 2003 to be exact - that we had our first official EM TC meeting. Its hard to believe that it has really been a year, but definitely not a boring year at that. With CAP positioned to move down the standard's path, we are in a good place to feel the influence and realities real world implementations will bring. I expect it will be a very exciting Year 2 for the group. 

At the same time, I felt like it would be a good idea to go back to our Charter and Requirements documents and see how we measured up. This is something I do fairly regularly, but thought it might benefit the group to open up the perspective and thoughts to all for feedback, comments, debates, etc. all in the interest of improving our efficiency and work. So, here it goes!

[Charter]
1.  Purpose of the TC is to design, develop, and release XML Schema-based standards that begin to solve real-world incident preparedness and response, in addition to emergency management, problems.

Status: CAP is our first effort, which is defined in XML Schema, so we are adhering to our promise!

2. These standards will not only provide a framework for data exchange, but also for functionality and service accessibility, all with the common goal of seamless application and data interoperability.

Status: CAP currently defines a format, but does not really address "seamless application and data interoperability" in terms of "a framework for data exchange". This is something our efforts in the IF SC is trying to address, so that we can apply to our work.

3. The core scope of this activity shall include, but is not limited to Unified incident identification, Emergency GIS data accessibility and usage, Notifications methods and messages, Situational reporting, Source tasking, Asset and resources management, Monitoring and data acquisition systems, and Staff, personnel and organizational management.

Status: We have formed 3 SCs around GIS, Infrastructure, and Notifications and Messaging. We have additionally taken part in reviewing and understanding DMIS, which provides a type of unified incident identification (or specifically, a unified method of exchanging incident information), and started looking into ICS forms. We still have some details we need to work through in each of these, as well as address some of the other core areas of activity.

4. Deliverables listed in the Charter.

Status: 
* Research related efforts (Q1 2003): Done - delivered in 2003.03.25 Requirements Document.

* Delivery of first draft of XML-based standard (Q2 2003): Done - PPW/Art graciously submitted CAP as a starting point for our first effort around the April 2003 timeframe. By the end of April, things were in full swing for defining the requirements, test cases, etc. for this effort.

* Compliance test suite and scenarios (Q3 2003): Incomplete - this has been talked around, about, and in some level of detail. At this point, in all honesty, we need to get a Working Draft published. We should have more than enough information from our own internal testing to start putting this on paper.  As discussed on the 2004.01.06 call (http://lists.oasis-open.org/archives/emergency/200401/msg00005.html), contributers to this effort need to join the MSG SC and provide the much needed feedback, thoughts, etc to bring this deliverable to closure.

* Publish best practices (Q3 2003): Incomplete - same status as test suite and scenarios. 

* Committee approval of first specification (Q4 2004): Done - delivered only about 6 weeks late on 2004.02.10 (http://lists.oasis-open.org/archives/emergency/200402/msg00031.html). Not bad at all!

[Requirements]
1. Be organized into Core Standards and Metadata Standards.

Status: CAP, our ICS work, etc. is a reflection of a Core Standard, while the transport/communication/exchange, registry, etc. efforts represent Metadata Standard (can be applied to CAP, ICS, or other Core Standards). So, we are staying true to our word. A revision of the Requirements should provide a clearer roadmap, however, of what we plan on delivering next and how that fits into the big picture.

2. All created schemata SHALL be considered designed in a way to represent modules and will collectively create an incident and emergency data interoperability framework.

Status: As it applies to CAP, we have addressed about half of this requirement. It is a module, but how that plugs into a larger "incident and emergency data interoperability framework" will have to be addressed in the implementer guides, etc. So, the jury is still out on this one for us.

3. All EM Core Standards modules MUST be interoperable with each other.

Status: Until we have a second one, we can not grade ourselves on this. Clearly we have kept this in mind as we have looked at ICS, etc., so we are staying true to the intention.

4. The EM Metadata Standards MUST interoperate with other designated standards.

Status: The IF SC has gone to great lengths to avoid re-inventing standards, however, nothing official has been created yet to really measure against this requirement. On the right track though.

5.  When reviewing existing standards and groups, the EM TC discovered many standards efforts already adopted and/or underway. In order to best leverage the existing work of these groups, any current implementation investments, and to avoid duplication of work and confusion, the EM TC will only focus on gaps that are present. The purpose of the EM Core Standards is to address these emergency and incident standards gaps.

Status: in a self reflecting and from a self criticizing perspective, I am personally not confident that we have stayed as true to this as we originally intended. At the same time, a lot of lack of confidence revolves around an unknown in the implementer's guide, and just how much normative/non-normative language the MSG SC will come up with. Example you ask? Well, there is a password element in <alert> *could* be an overlap with other security/authentication standards out there. But again, it may not be - depends on how we recommend its implementation.

6. By creating EM Metadata Standards we will supplement these existing standards, as well as the EM Core Standards, with information to facilitate interoperability between multiple areas of concentration.

Status: again - we have not created anything official here yet, so we can not rate our effort quite yet.

7.  The purpose of the EM Metadata Standards is to provide these key semantical attributes to existing standards in a way that does not prohibit them from functioning as is, but rather to add additional information, in a non-obtrusive way, to allow for greater interoperability between the standards and the systems that have implemented them. As shown back in Figure 1, the end result of applying the EM Metadata Standards to the EM Core Standards and other standards, is an operationally transparent data layer that is available, if needed, to help apply consistent context to incident and emergency data.

Status: while we have not created any Metadata Standards, and I know I will get a HUGE disagreement from some of you on this, but will say it anyway, the topic of *how* to include binary data, I believe, should fall here - in a Metadata Standard. I say that because it is a challenge beyond CAP - that will most likely apply to quiet a few of our efforts. Of course Incident types, severity, etc. also fall here. Will leave it at that.

8. The EM Core and EM Metadata Standards SHALL be produced in accordance with OASIS principles and policies with regard to open, public standards processes, and intellectual property rights.

Status: as far as we know, we are doing this :)

9. We wish to make it clear that an application which uses an EM TC Specification for any application with a modification that renders that or any unmodified specification obsolete or unusable in whole or in part SHOULD NOT be allowed. 

Status: while I truly hope we are adhering to this, again, *how* we discuss the use of CAP in the implementer guides will ultimately determine what "modification" means. For instance, is applying a specific method of transporting CAP, which one could argue makes an "unmodified" implementation unusable (they picked RSS and you picked Web Services), consider a modification? I don't know the answer, but something we should consider.

10. When and where possible, feedback from developers, implementors, and users SHOULD be sought to improve the usability of all EM TC Specifications.

Status: we have had a test, feedback loops from Art's CAP list(s), Public Reviews, etc. and we are going to be talking to OASIS on how to further promote adoption, which will bring in even more feedback. We are living up to this fully.

11. EM TC Specifications MUST conform to XML Schema Part 1: Structures and XML Schema Part 2: Datatypes syntax and rules.

Status: CAP was building using XML Schema, so we are good there too.

12. EM TC Specifications SHOULD also leverage and/or be compatible with RDF, XHTML, SOAP, and WSDL. 

Status: we do not absolutely have to do this, but SHOULD is often considered what an implementation would do to support a standard (aka all MUST and SHOULD generally ensure you support). I am personally not aware of us doing anything that prohibits this, but it is something the MSG SC can confirm/reinforce with the implementer guide.

13. Terseness SHOULD be sought. This is to be considered a guiding principle. By adopting this principle as a requirement at this level of commitment, the OASIS EM TC aims to ensure greater compatibility through a lack of unnecessary complexity.

Status: I think we have been very successful at this - maybe even too much. The public's embrace of CAP should be a great indicator.

14.  The EM Core and EM Metadata Standards MUST be extensible.

Status: we inherit some of this by the very nature of using XML Schema, where schemata can be imported to create larger definitions, languages, etc. We have done well here too.

So, what now? Well, we do need to finish up CAP, and by "finish up", I mean flush out the other deliverables we defined in our original charter. We should also consider revising our charter to reflect, when done, the completion of those deliverables and make it a little less specific in what is next, but rather give it the wings it needs to fly 2 - 3 years into the future.

Hope this has been helpful to the group, and enjoy!

Allen

--
R. Allen Wyke
Chair, OASIS Emergency Management TC
emergency-tc@earthlink.net