Emergency Management RIM SC Meeting Notes 04/11/2017

Attendees: Rex Brooks Jeff Waters Elysa Jones Karen Legrand-Guest

Emergency Management Reference Information Model Subcommittee Report/Discussion

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

Rex noted that our policy proposals were ratified by the EM TC and so it is now on us to follow through.

1. Ideally, all of our schema should validate standalone in BOTH XMLSpy and Oxygen. 2. Any import statements in any of the schemas in our EDXL standards, where the imported schema isn't used, should be removed. 3. All imports should be local (so that everything validates standalone, i.e. disconnected from the web) 4. Only one schema file should be imported into one namespace. 5. Make a RIM recommendation to the EMTC that the EMTC "Require that any new EDXL standard have a zip with a standardized folder structure, including "schema", "ImportedSchema","examples", and "Require that everything in the zip file must be tested to validate with BOTH XMLSpy and Oxygen"

We voted to approve Rex’s motion to make a change in the imported schema for EDXL- HAVE-v2.0 in edxl-ct-v1.0-wd06.xsd as well as in edxl-have-v2.0.xsd from edxl_xAL.xsd to edxl-xAL.xsd and from edxl_xPIL.xsd to edxl-xPIL.xsd. Elysa seconded the motion and all were in favor with none opposed or abstaining.

Rex asked Jeff to report on what else needs to be cleaned up in edxl-ct-v1.0-wd06, and Jeff responded that historically, when we need to insert elements like contact elements into our specifications or specific messages based on those specifications, we reuse other standards, such as CIQ, standards but we tend to neglect to deal with the consequences of importing other standards or committee specifications. He suggested we might use specific urls at those points in specifications or implementation messages to refer to other specific sources rather than importing or embedding them in our specification. This is the concept of linked data via JSON. Rex expressed some reservations and Karen noted that the obligation to maintain the referenced website was problematic. Jeff brought up our permathread about offering alternate representations, specifically JSON. Rex noted that he had already performed conversions for all of our EDXL specifications from XML Schema to JSON Schema. Jeff suggested that we develop class libraries and online validators for our EDXL schema. He also suggested a binary protocol buffer similar to what Google uses with their CAP Validator. We were all in favor of doing this.

Jeff suggested we bring this up to the TC to get something of an official nod to go forward with this.

We continue to note specific points in the ongoing record of our discussions of items in the bulleted outline below, adding dates to track our discussions. Note there was insufficient time to get to further discussions during this meeting.

 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. o 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 o 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. o 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 o Relational Database schemas . (2-14-2017) Rex said that he is sure that we can do this with the Ultimate edition of Enterprise Architect o 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? o 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).  Can we find a host for persisting any framework-toolkit components we produce? Is OASIS a good place for it?  This is all in addition to the work we need to do to identify and communicate with as many stakeholder groups we can.

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

Respectfully Submitted, Rex Brooks