Emergency Management RIM SC Meeting Notes

08/15/2017

Attendees:

Rex Brooks

Elysa Jones

Jeff Waters

Emergency Management Reference Information Model Subcommittee Report/Discussion

We had a quorum, and we approved the Meeting Notes from 8-01-2017 as amended with all in favor and none opposed or abstaining.

We began by discussing the presentation on the EDXL Framework/Toolkit.

Jeff congratulated Rex on the excellent quality, content and comprehensiveness of the slides. He noted a couple minor changes and suggested that the number of slides and the selection of slides could be adjusted to fit any particular audience.

Rex acknowledged this, saying that it was originally aimed at the EDXL Workshop, but wanted to have

·  an initial presentation to the EIC July 26, 2017

·  with another webinar including added material addressing the use of EDXL-DE with CAP in the context of the reference implementation in the special EM TC meeting Aug. 22, 2017

·  before the presentation to the EDXL Workshop September 22, 2017.

So it is aimed at

·  software developers who implement CAP and EDXL-DE in the context of the EDXL Framework/Toolkit,

·  emergency managers who make decisions about the software chosen to use in their respective organizations/jurisdictions, and

·  stakeholders with an interest in the ongoing development of the EDXL suite or family of standards and specifications.

Elysa said she wants to have it vetted by Gary Ham and Eliot Christian before the next presentations. Rex said it was ready in its current version for that vetting and should be done sooner rather than later to allow time for implementation corrections, suggestions, etc.

Elysa went over the planning for the announcement for the Aug. 22nd presentation.

There being no further business, Elysa made the motion to adjourn and Jeff seconded. All were in favor and the meeting was adjourned.

Respectfully Submitted,

Rex Brooks

We continue to include unfinished business with regard to the Framework/Toolkit (with some updates with date it was discussed.

·  What would it look like (features wish list)? We suggested

o  JSON and/or JSON-LD versions of our specifications and/or profiles of our specifications linking data objects across web-based application. This because they’re currently popular

§  (1-17-2017) We want users to adopt our standards so the standards must be flexible enough to represent standardized emergency information-in machine and human-readable form.

§  (1-17-2017) Rex asked if Jeff had reviewed the sample JSON conversion he sent in an email to Jeff. Jeff did note that and explained how those JSON files can be converted easily as JSON-LD. Jeff said he could provide an example that Rex can use as a model for other EDXL specifications.

§  (1-31-2017) Jeff continued discussion of his email to Rex 1-22-2017: He noted that the example he provided in which he noted that the way he converted a CAP alert message from xml to JSON-LD and we discussed it in some depth. Rex said that he understood the explanation.

§  (1-31-2017) There are two main efforts that we are moving forward with: Jeff is investigating the particulars of the Google CAP validator/protocol buffer wherein CAP data is converted to a binary format that can be output to several different formats, such as XML or JSON; and Rex is looking at ways to produce the flat list of JSON key-values from Jeff’s email example in JSON from our hierarchical EDXL XML Schema.

Libraries for Microservices?

§  (1-17-2017) Jeff noted that he was attracted to the CAP Validator https://cap-validator.appspot.com/ by Google, which puts values in a table with a geographic map that references a CAP library that can read in a CAP message and translate it into JSON using a small protocol buffer. He said that they use a binary format with instructions to developers on how to use that, so if we had the same sort of binary library similar to the CAP Validator which uses Google’s protocol buffer to enable reading and writing CAP messages for our EDXL standards, it would be a big help.

§  (2-14-2017) Jeff reported that he was looking into other data-serialization options that could work for binary libraries

§  (6-20-2017) Jeff noted that he was working on adapting the react jsonschema playground formbuilder available at https://mozilla-services.github.io/react-jsonschema-form/ for the EDXL-DE-CAP combination and thence for the whole EDXL suite/family.

What information/Microservices?/features do developers need to know about and use for their new Apps?

§  (2-14-2017) Rex said he would take this question to the Adoption TC and see if he can get Tom Ferrentino interested in gathering this information.

Can we make our emergency-based information usable in an everyday context and what can we do to provide this?

§  (2-14-2017) Rex said that his work on JSON and in using Enterprise Architect to produce Java classes for our EDXL specifications had opened up his thinking about how to craft streamlined resources for Microservices which could lend themselves well to simple user-facing apps for purposes beyond emergencies but which could be used in emergencies

Relational Database schemas

§  (2-14-2017) Rex said that he is sure that we can do this with the Ultimate edition of Enterprise Architect

§  (6-20-2017) Rex again indicated that this could be done in Enterprise Architect and added that basic java classes for all elements in a given specification can also be produced,

Look at innovation in the open source arena for a model for grass roots adoption How did Linux do it? Apache? MySQL? How did Big Data get going once the need was understood?

Think about working with Gary on an IPAWS model. We did the IPAWS Profile, so how can we build on that with perhaps a Custom Validator like the Google CAP Validator?

·  What would developers actually use? (If we build it, will they come?)

·  What can we actually produce? (Libraries, Profiles, Reference Implementations, Database Schema, etc).

Relational Database schemas

§  (2-14-2017) Rex said that he is sure that we can do this with the Ultimate edition of Enterprise Architect

§  (6-20-2017) Rex again indicated that this could be done in Enterprise Architec

§ 

No-SQL Database schemas

§  (6-20-2017) Update: Both Rex and Jeff have experience with MongoDB to produce schema for the specifications, though there is no tool for automatically producing them from xmlschema that we are aware of as of this date.

§ 

Java Class Libraries

§  (6-20-2017) Update: It is noted that basic java classes for all elements in a given specification can also be produced in Enterprise Architect based on smlschema.

§ 

.Net Class Libraries

§  (6-20-2017) Update: It is noted that basic .Net classes for all elements in a given specification can also be produced by Xsd2Code

§ 

·  Can we find a host for persisting any framework-toolkit components we produce? Is OASIS a good place for it?

o  (6-20-2017) Update: It is noted that OASIS allows/enables GitHub Repositories with someone to administer it actively

·  This is all in addition to the work we need to do to identify and communicate with as many stakeholder groups we can.