Emergency Management RIM SC Meeting Notes
10/10/2017
Attendees:
Rex Brooks
Jeff Waters
Elysa Jones
Emergency Management Reference Information Model Subcommittee Report/Discussion
We had a quorum, and we approved the Meeting Notes from 8-29-2017 as amended with all in favor and none opposed or abstaining.
Review Agenda Item 1: Enforcement of package structure, document and schema policies.
We began by discussing the issues around the fact that EDXL-HAVE-v2.0-WD03 is about to complete its 30-Day Public Review. Specifically, we discussed putting our newly-established policies to the test and if we would like to add some new measures to those we have already established. In particular we noted that imported schema for edxl_xAL and edxl_xPIL need to be changed to edxl-xAL and edxl-xPIL. Rex took this action.
We noted that we now have a new ‘Policy Notes’ folder in the EM TC Document repository where all policies can be documented by citing the dated meeting notes in which policy decisions were voted on in a policies document. We will report this up to the TC. Rex took this action contingent on specific reports from Jeff.
Review Agenda Item 2: New schema and ImportedSchema policies.
We reviewed the requirement that all new specifications or new versions of specifications no longer include imported schema with working draft status, e.g. only use the current numbered version which I believe is v1.0 for edxl-ct, edxl-gsf and edxl-ciq.
Jeff noted again the problem with the way that the http://docs.oasis-open.org/emergency directory structure is confusing as noted in edxl-de-v2.0 where we have another working draft schema example. We discussed how this can be addressed again later when we take up the next Committee Specification revision of edxl-de v2.0, while starting this process with the work on the EDXL-HAVE-v2.0 Committee Specification Public Review.
Rex reviewed his suggestion to put in an asterisk(*) to indicate at each appropriate directory level which selection leads to the “latest official standards-track version” of a given specification with the appropriate legend at the top or bottom of the directory page. We agreed to ask TC Admin Chet Ensign if we could do that, starting with EDXL-HAVE-v2.0. Rex took this action.
Review Agenda Item 3: Profiles and Extensions and Camel Case Policies
We reviewed the work we need to do to update documentation of the Profiles and Extensions work as well as the Camel Case change and Jeff took the action to report on Profiles and Extensions. We excused Elysa from documenting when these were addressed in the EM TC in light of the workload she is currently addressing for the recent events involving the EDXL-HAVE-v2.0 Committee Specification Public Review and its presentation to the HL7 Plenary and Working Group meetings in San Diego, California and the CAP and EDXL Workshops in Rome, Italy.
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.
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
§ (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.
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
§ (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,
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).
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
§ (6-20-2017) Rex again indicated that this could be done in Enterprise Architec
§
o 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.
§
o 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.
§
o .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.