EIIP Virtual Forum Presentation – June 4, 2003
OASIS Emergency Management Technical Committee
Advancing Incident Management with Open XML Standards
R. Allen Wyke
Chair, OASIS Emergency Management Technical Committee
Chief Technology Officer, Blue292
Amy Sebring
Moderator, EIIP Technical Projects Coordinator
The following version of the transcript has been edited for easier reading and comprehension. A raw, unedited transcript is available from our archives. See our homepage at http://www.emforum.org
[Welcome / Introduction]
Amy Sebring: On behalf of Avagene and myself, welcome to the EIIP Virtual Forum!
Our topic today is "The OASIS Emergency Management Technical Committee: Advancing Incident Management with Open XML Standards." OASIS stands for "Organization for the Advancement of Structured Information Standards," and is a not-for-profit, global consortium that "produces worldwide standards for security, Web services, XML conformance, business transactions, electronic publishing, topic maps and interoperability within and between marketplaces."
Here is the Web site for the Technical Committee:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=emergency
Now, I am pleased to introduce our speaker, R. Allen Wyke, the Technical Committee Chair. Allen is also the Chief Technology Officer of Blue292, a leading Crisis Information Management System (CIMS) software provider for the Incident Process Management (IPM) space. Mr. Wyke has published a dozen books and numerous articles on various Internet technologies such as XML, JavaScript, .NET, and Perl. Please note that his email address is posted on the Web page if you wish to follow up with him after the session.
Welcome, Allen. We are very pleased to have you with us today. I now turn the floor over to you.
[Presentation]
R. Allen Wyke: Thanks, Amy, and thanks to all who have joined us today. We are going to talk about the OASIS Emergency Management Technical Committee (EM TC), when it started, where we are going, and provide a current status.
The EM TC first saw light within the EM-XML Consortium, which was announced in October 2002. The Consortium's effort is focused on researching, designing, developing, and evangelizing standards in the world of incident and emergency management.
Since its inception, the group has attracted the attention of numerous public and private companies, individuals, and agencies currently totaling a representation in excess of 40 institutions. To increase focus and ensure the success of our efforts, the Consortium formed an Executive Committee (EC), Chaired by Matt Walton of E Team, and a Technical Committee, which I Chair. The EM TC, which we will be discussing today, is chartered with building XML standards within OASIS - a well-known standards body.
Before I begin discussing the EM TC, let me take one minute to talk about XML and standards. XML, which stands for the eXtensible Markup Language is a W3C Recommendation (i.e., standard) that allows us to define "languages." These languages are represented as "tags", which are then wrapped around data, such as in <important>stuff</important>. By including these tags, programs are able to better process any data being exchanged which therefore reduces the amount of effort end users must apply to understand what, where, how, and why data looks or is processed a certain way. In the little example we just provided, it is, for instance, easy to see the "stuff" is important.
Armed with XML as a means to create languages to describe data, we are able to standardize on how to share data in much the same way industries have standardized on everything from the color of major appliances and car tire sizes, to electrical plugs and phone jacks. Sure, there are variations, but they are minor when compared to a world where we all had our own standards.
The purpose of the EM TC is to design, develop, and release XML Schema-based standards that begin to solve real-world incident management problems. These standards not only provide a framework for data exchange but also for functionality and service accessibility, all with the common goal of future seamless application and data interoperability. Our charter not only defines this purpose, but it also outlines our deliverables for 2003. These deliverables included the researching of existing standards and standards bodies (Q1 2003), first draft of the first XML-based standard (Q2 2003), compliance test suite, scenarios, and best practices to be used by implementers (Q3 2003), and committee approval of our first specification (Q4 2003).
Since the first meeting of the EM TC, on February 11, 2003, the group has created a Requirements document to outline our Phase 1 tactical efforts. Out of this document, which is accessible from the OASIS Website, the EM TC has formed three initial Sub-committees (SC) in the areas of Notification and Messaging (EM MSG), Infrastructure Framework (EM IF), and Geospatial Information Systems (EM GIS). In addition to these initial areas of focus, the EM TC has also identified the following as a priority for Phase 2: asset and resources management; areas around financial tracking; areas around public health.
It is with great pleasure that I announce we are right on schedule with our deliverables and expect to have a formalized Working Draft of the Common Alerting Protocol (CAP) released by the end of June. Many of you may have heard of CAP, which has been brought in under the TC by Art Botterell who is with us today. Art is now the Chair of the EM MSG SC and is representing the Partnership for Public Warning. This group is working on sharing alerts, notifications, and ICS information in a standard way.
While Art and his team are hammering away at CAP, the EM GIS SC, which is Chaired by Eliot Christian of the Department of the Interior, has a short term objective of providing GIS expertise to CAP. Like any work in this space, we want to ensure our standards have the proper geospatial influence to be fully utilized by applicable GIS-enabled applications. In addition, the EM GIS team is also ensuring we stay on top of other GIS-related standards efforts, such as those at the OpenGIS Consortium (OGC), as they related to emergency management.
Last, but certainly not least, our EM IF SC, which is chaired by Rick Carlton of E Team, is currently helping CAP in the areas of encryption, authentication, and overall security. Basically, making sure the CAP standard can get from point A to point B in a safe and secure way. Long term, the group will begin to define the necessary infrastructure framework to facilitate end-to-end emergency and incident data and service interoperability.
So, what does all of this techno-babble mean? How does it really help and impact what you all do day-to-day? Why should you care?
First, it means major emergency and incident software vendors are creating standards that will allow our applications to work together better. To illustrate this point, how many software applications do you have, but can no longer use because it does not connect with another system or it is built on a proprietary platform you can not extend? Have you had instances where you liked the GIS technology from Company A, incident management software from Company B, and alerting technology from Company C, but they did not all work together? Our efforts will help in these scenarios.
Second, how many times have you funded a custom project only to find out your governing CIO or Director has standardized on a different approach your project was unaware of? Since this is an open standard, it means even your own projects, engineers, and/or developers can create applications to support these standards. And, by supporting the standards, these applications now inherit some of the benefits of being standards-based. For instance, they interoperate with other applications - ones you didn't have to write. This is another area the EM TC efforts will benefit you.
At the end of the day, I do not think anyone would argue that we are in need of advancements in the area of emergency and incident management to automate some of the more mundane tasks. To automate in order to allow experts, like yourselves, to do what you do best, which is manage and/or respond to events. You shouldn't have to worry about how to get a hold of Bob or make sure Susie has the right information, yet you do.
While our efforts at the EM TC do not solve all the world's problems, even a 10% improvement in the situation can save assets and lives, and we accomplish this by taking one strategic step at a time.
I will leave it there, and we can get more into your areas of interest based on your questions, for which I turn the session back over to our Moderator.
[Audience Questions & Answers]
Question:
Ken Gill: Are computer aided dispatch systems considered in the suite of incident software applications?
R. Allen Wyke: That is an excellent question, Ken; let me try to answer. What we, and I am sure most of you, have found is that the range of applications, services, tools, resources, etc. that span the world of "incident" is vast. There are MANY different applications that can fall into this category. CAD certainly has a role within IPM (Incident Process Management) and general emergency management. "How" it applies, can vary, as you might imagine.
Question:
Howard Berkowitz: We develop healthcare applications that are finding increasing emergency use. At present, we use HL7 Version 2.x that is non-XML, but version 3 is going XML. Two-part question: to what extent do you look at HL7 at all, and does XML-HL7 come under your scope?
R. Allen Wyke: Another good question. In our original efforts to research other standards efforts, as well as industries/verticals, where emergency and incident management was applicable, we identified, very quickly, that health care was an area. We also spoke specifically about HL7 and where it fit in. We've been generalizing its idea of "patient" to include both victims, as well as responders that the safety officer has to track. In order to try and bite off an area that we could focus on and address, we created a Requirements document that outlines our initial (a.k.a. Phase 1) focus as well as referenced our secondary (Phase 2) focus. Health care fell into the Phase 2, but we do have the EM IF SC looking into now to be ready.
Question:
Charles Werner: What impact will XML have on existing notification services that are presently provided free of charge to the public?
R. Allen Wyke: Going right for the punch! Good question, Charles. The idea isn't so much that XML will/should affect, in any way, these types of services, but rather make it easier for the creator/vendor to offer services. In a nutshell, if supporting a single (or even a few) standards allows them to now support 200 different connecting applications, then they save money. Even here at Blue292 we interoperate with other 3rd party vendors. By supporting CAP, as an example, we will be able to build a single "connector" that can work with others, rather than building one for each. It reduces my overhead cost of developing software that makes me and my Board happy.
Question:
Avagene Moore: Two questions, Allen: Who and how can folks get involved with the Technical Committee? Also, how do those of us who are not directly involved in the overall OASIS work stay abreast of its progress?
R. Allen Wyke: To be directly involved, an individual/company must first join OASIS. At that time, they can join our TC (or any other for that matter.) As for indirect, individuals can watch our Web site that you provided earlier. From there you can read email threads, review standards drafts, and even submit comments through our public email list.
Question:
Paul Lebar: Given that there are other standards in existence and currently under development that address the same need, what will motivate developers to choose to implement this standard over others?
R. Allen Wyke: One of the first things we did was research the standards that are already in development or deployed. In fact, this is an ongoing process. The standards we are creating are actually not addressing the exact same need. We have made great strides to try and avoid overlap, although the more input we have from others, the better off we are in fulfilling this objective.
Question:
Charles Werner: Follow up - what impact will that have with the XML, tags, etc. during extreme bandwidth limitations during 9/11 like incidents?
R. Allen Wyke: Bandwidth is certainly a concern. But it is really something that is the responsibility of the implementor. By that, I mean that we are focused on defining the standards around the data that allows implementors to exchange information as they need - something that is currently difficult. If the delivery of that information has to go over a low bandwidth connection for the "last mile," then the implementor, who would be most versed in the needs of its "customers", would address that. That being said, our EM IF SC is/will be making recommendations as to how to achieve this. We fully acknowledge, and accept that the more we can provide implementors in terms of recommendations, best practices, and guides the better our adoption.
Question:
Charles Werner: I understand that we use the Emergency EMail Wireless Network without XML. They will not link, correct? Simply stated, without XML other products will not play, correct?
R. Allen Wyke: Not necessarily. What XML provides is a "standard" way to communicate. Think of any highway. The paved road "standardizes" how you get from A to B - it provides some structure. Yes, vendors can go "off road" and not support standards, and they can even have a good reason but the majority of applications benefit from it. That being said, for existing services, applications, etc. we are trying to create standards that make their current and future products easier to create and provide better value.
Question:
Amy Sebring: Allen, when you researched existing standards, did you just research technical standards, or did you also research standards of professional practice for example? If so, what did you find and how will it fit into the development of the XML standard?
R. Allen Wyke: Can you please define "professional practice"? Are you referring to process/methodology for creating standards?
Amy Sebring: I am referring to how incident responders/emergency managers do their jobs.
R. Allen Wyke: Understood. In developing our standards, we do not just start with XML. We actually spend a significant amount of time understanding the "problem." During this, we develop what we [engineers/developers] call use cases. For instance, how would CAP be used in sending weather alerts? These use cases provide a real world scenario where our standard would/could be applied. This helps ensure what we are building works.
Comment:
Art Botterell: One of the challenges in this work is getting both the best technical expertise and the best practical ("subject expert") professional insights and we're constantly working, in a variety of ways (including sessions like this) to make sure that both perspectives are fully represented. But just for clarity, we aren't trying to rework emergency management practices, just support them better!
Question:
Howard Berkowitz: XML lends itself to application-level compression, at a couple of levels –binary tags established at session setup and compressed information formats ID'd by tags. Is your INF or other W3C group working on this? Example, you are sending geographic coordinates, <foo5>, that you know are internally 16 bits. <foo5>12345</foo5> is 16 bytes, [esc][code][16 bits] is 4 bytes.
R. Allen Wyke: Good question. What we are focused on, at least initially, is the definition of the data. The definition of <foo5> for example. However, the EM IF SC is chartered with looking at other standards, such as encryption, compression, etc. that apply to how to use our data definition standards. So, the short answer is no, we are not defining standards for compression, but the long answer is yes. We are in fact reviewing and will be making recommendations (not requiring) to our implementors on what standards to use.
Question:
Jeff Silberberg: Is there going to be a process to certify a vendors implementation, and will it be Server/Client or product-based?
R. Allen Wyke: Let me try to address that. While we are not going to create a new "authority" that certifies our standards, part of our charter is to provide a test suite for implementors to test their implementations. This is very similar to how the W3C handles HTML/XHTML. While there is no authority that polices Web site to make sure they are HTML/XHTML compliant, they do provide a validator if you or your Webmaster wants to see if their pages are compliant.
Question:
J. W. Tamargo: Since XML is relatively new, how do we know that it is not a passing fad and there will be another new standard?
R. Allen Wyke: XML, especially in today's fast paced computing world, is not as new as you might think. The first standard was released in February 1998, and considering that mainstream computing didn't hit until 1993 or so it’s been around for quite a while. At the same time, Oracle, IBM, and Microsoft (3 largest software companies in the world) are MAJOR backers of XML. Just about every single one of their software products support it in some fashion and with the initiatives of .NET (Microsoft) and Web Services in general (heavy XML usage), it is definitely here for a while.
Comment:
Gary Ham: This is more of a comment on the professional standards question from another TC member. Presidential Directive #5 calling for a National Incident Management System (NIMS) cals for Incident Command System processes to be followed. We are defining our work based on the processes in the manuals and the contents of the forms (where it seems to make sense.) I guess you could say the ICS process is a sort of sanity checker for our work.
R. Allen Wyke: That is a good point Gary (who is a MAJOR contributor to our efforts by the way). ICS is something Art's group (EM MSG SC) is reviewing, and most certainly HSPD-5 is on our radar.
[Closing]
Amy Sebring: That's all we have time for today. Thank you very much, Allen, and we wish you every success in your efforts. Please stand by a moment while we make some quick announcements. If you are not currently on our mailing list, and would like to get program announcements and notices of transcript availability, please see the Subscribe link on our home page.
We have two new partners since our last session, one of whom is an old and dear friend (who remains ever young!)
Sand City (CA) Police Department, POC: Russell Coile, PhD, CEM, Disaster Service Coordinator, URL: http://www.sandcity.org/police/index.html .
We also welcome a new friend, City of Grand Prairie (TX) Environmental Services Department, POC: Jennifer Vuitel, Environmental Educational Specialist, URL: http://www.gptx.org/envsrvcs/eshome.asp .
The newest EIIP Partner is "Office Nurse PRN" with Fran McAfee Rosenberger, RN, Owner, serving as the EIIP POC. Fran is with us today. Fran does not currently have a Web site.
If your organization is interested in becoming an EIIP Partner, please see the Partnership link on our home page.
Thanks to everyone for participating today. Our session is adjourned but before you go, please help me show our appreciation to Allen for a fine job.
[Addendum: To provide feedback and comments to the Technical Committee, send to emergency-comment@lists.oasis-open.org ]