|
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:
- Attendance
- Review and dispose Meeting Notes from 1-31-2017, 2-14-2017,
and 2-28-2017 if available
- Discuss the Proposal from the Issue 105 noted above:
- (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.
(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) 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.
Cheers,
Rex
--
Rex Brooks
Starbourne Communications Design
Email: rexb@starbourne.com
GeoAddress:
1361 Addison St. Apt. A
Berkeley, CA 94702
Phone: 510-898-0670
|