OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-rim message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: New Issue in JIRA and Agenda for Tomorrow's Meeting

Hi Everyone,

I wanted to alert you to a new issue, EMERGENCY-105, I put into the Issue Tracker in JIRA https://issues.oasis-open.org/browse/EMERGENCY-105?jql=project%20%3D%20EMERGENCY It is the first of several and it will be on the agenda for tomorrow's meeting.

The Issue doesn't seem to include the Description so I'm including it here:

The practice of allowing multiple imports of external helper schema supporting the main schema of EDXL specifications has led to problems with duplication and with missing imports from imported schema that are not available locally. These problems are exacerbated by differences in the way xml parsers handle imported schema.

The Proposal for this issue is included, and it is on the agenda:

  1. Attendance
  2. Review and dispose Meeting Notes from 1-31-2017, 2-14-2017, and 2-28-2017 if available
  3. Discuss the Proposal from the Issue 105 noted above:
    1. (1) Ideally, all of our schema should validate standalone in BOTH XMLSpy and Oxygen.
    2. (2) Any import statements in any of the schemas in our EDXL standards, where the imported schema isn't used, should be removed.
    3. (3) All imports should be local (so that everything validates standalone, i.e. disconnected from the web)
    4. (4) Only one schema file should be imported into one namespace.
      (In future, we could consider using the standardized OASIS Catalog solution for providing a local repository of schema (e.g. Oxygen implements one by default) which would allow for the best of both worlds in theory, i.e. you can use import statements to the official schemas on the web, but store those schema in a local catalog and the validator will check there first, so it still works if you are disconnected from the web. But one reason for not doing this is that it hides the schema locations and makes everything a little more complicated.)
    5. (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"

    4. Review bulleted items carried over in the Meeting Notes and included below:
  • What would it look like (features wish list)? We suggested
    • 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
  • 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
  • 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).
  • 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 is a lot going on. I've got some fairly interesting things to report on.


Rex Brooks
Starbourne Communications Design
Email: rexb@starbourne.com
1361 Addison St. Apt. A
Berkeley, CA 94702
Phone: 510-898-0670 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]