[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Meeting Minutes: 2003.07.15 (delayed)
Was going back through the minutes and it appears these were never
posted to the list, though they were posted to the Minutes link on the
public site in PDF format. Cathy dug them up, so I could send out. With
any luck, we will be able to use the search feature soon to search
these.
Sorry for the admistrative nature of this - Allen
-----------------------
Emergency Management Technical Committee
July 15th Meeting Minutes
[Attendees]
Attendees are tracked on the EM TC section of the OASIS website.
[Welcome - Allen Wyke]
Thank you to Gary Ham and Battelle for hosting this meeting at its
facility.
Since DMI-S held a meeting to demo its API's to the EM-XML Consortium
this morning, it was decided to have mini face-to-face meeting for the
TC- not required to attend in person.
* Purpose: Getting update from Art and hash through remaining issues
* End result: Have individuals to do reference implementation and
implementer guide -- all to drive adoption. This will give outside
group have some resources to go to.
* Today's focus is on CAP (Common Alerting Protocol). Walk out today as
to what CAP is and how we utilize in our industry and products and
services that we have.
[Update on CAP - Art Botterell]
* Background from social science. Single warning of message doesn't
work - must get message through multiple channels/technologies. That
was the problem that CAP was initially targeted to solve.
* Object model of what generic notification was - realized notification
was bigger than realized.
* Moved out of PPW. Art sponsored by PPW to bring to broader set.
* The message form of CAP: XML schema
1. Header (alert)
2. One or more blocks of inform
3. Each block has one or more location elements
* Evolved through one and a half-year process of mailing lists. Then
brought into OASIS to refine.
* Draft spec released on 6/23 for public comment.
* Public comment period (30 days) closed at end of month. Subcommittee
had some small comments but no other major comments.
* Hope that by 8/1 subcommittee will be recommending draft 1.0 for TC
approval.
* Pending changes in 0.9 draft is in language for geospatial
recommendation
+ GIS group recommendation for congruence with OpenGIS practice -
change element of polygon to be compatible with
+ How to express frames of reference for geocoding. Key = values
pair.
+ May be more advantageous to do in other ways. Active discussion on
how to deal with attached assets - if by inclusion, by what format
(audio, image file attachments).
+ These will be minor changes so no difficulty to get to 1.0 version
* Allen - let's go over spec itself to familiarize people with
sections. Use the White board and identify sections
* David - what about DIJ issues from John Aerts.
* Draft 3 Justice XML dictionary should refer to draft - after Art had
conversations with them. Elements in data set potentially in conflict.
Mapped all names to use naming convention - couldn't get info on what
rules were. Decided to stay with easy name space. It will be just a
mapping issue so trivial. Then will cross brief 1.0 folks at Georgia
Tech who lead that area.
* eGov naming conventions was never mentioned - not brought into
committee process. Are open to receiving input. May be an issue that
we take up as committee process. Given that it has separate name space
may not be a huge problem.
[CAP Documents]
* Preface
* Recapitulate requirements and use scenarios from development process
+ history
+ applications
+ design philosophy
* Collection of all intermediate documents
* Object Model
* Data dictionary - here is where elements are actually defined.
Elements and structures are reusable - for general principle don't have
immediate need for reuse
* XML schema - machine readable
* Set of example messages based on schema (weather, seismic data, amber
alert - examples of applications that can be made of it)
[Point for discussion]
Alert Message Structure Object Model was displayed for any structural
discussions
Is pretty close to being implementable. Some implementations predate
OASIS work (0.6 level). Three revisions have been done within the work
of subcommittee. Close to freezing 1.0 so issues need to be addressed
need to be tabled with subcommittee now.
[Allen - Issues for standards (reference other objects, attachments)]
* Parallel effort working on attachments
* Context for geocode (geocode being an element)
* Standardize on incident types conversation -- is a bigger issue.
Jerry drilled in it very deeply and came to the list that we have as the
"least bad" list that we can come up with. Meta issue is that do we
want to spin out as separate ongoing issue. Does that taxonomy have
issue in other message types. Whatever we get to will dissatisfy some
but nobody has identified better list. Anything in list that shouldn't
be there - hurting anything with each individual items.
* Gary - whenever we look at this type sets do we really want to
standardize or allow to grow in some fashion?
* Art - not sure of still whether this element is still helpful. Causes
us trouble because not clear for us what use case for it is. Bigger
question - does it really need to have it?
* Dave - can we throw out to group to come up with a use case? So we
can say give us a valid user
* Allen -Answer may lend itself when doing reference- does or does not
need to be required.
* Gary -started looking at reference implementation and internally
compared to internally incident types and has some overlap some
different. In context of CAP types that are there are appropriate for
CAP, but may have different definition of incident then may change
corresponding set of incidents
* Rick - category section - purpose of CAP notification to announce
something is happen or forecast - alert of warning, not an execution of
process against event which goes more to the heart of incident type.
[Geocode Issue within CAP]
* Context for geocode - allowing areas to be defined by point and radius
circle diagrams, also allow area to be defined with geocode - provides
backward compatibility to EAS. If in infected area needs a coding
scheme.
+ One answer - has optional FIPS tag - demand every receiver have a
FIPS table. Polygon would be arbitrary scheme that receiver may not know
about.
+ Another way to receive compatibility with EAS?
* Allen - in past created a hint element - not required but let me try
and help you figure out what is required - further describes data if
know how to use it and if not no worse off.
* Art - Currently description and geocode could be complete area - then
its not optional when interpreting message. Leave it to the gateway of
EAS to figure out what FIPS code is required. But then leaves to the
responsibility of receiver.
* Brian - maybe allow to embed element from different namespace instead
of making up arbitrary strings.
* Rick - NIMS has adopted a specific standard and hope that NIMS will
determine
* Gary - NIMS will aggregate and will be able to use any
* Brian - just if that's true then people using different codes can use
different strings and that needs to be fixed. Come up with numeration
* David - Make one up if none of these fits.
* Allen - back to required or optional. Is it really required
* Art - is mandatory unless you have done a polygon or circle (per
Eliot).
* Allen - scenario of physically condition not relevant - Art - area
block is optional
* Rick - use scenario. Security monitoring for petrochemical sites He
is doing B2B and have individuals agree to monitor camera bays for
which they are pain min wage. In this context, the Petrochemical site
needs to be referenceable but point of specific occurrence may not need
to be reference. How granular do we want to get? Eliot's categorized
as conditional but I would call it optional
* Art - only use case is backward compatible with EAS. We are guessing
that NIMS will support EASEAS codes used in weather radio, also used by
dept of agriculture. FIPS codes refer to county boundaries only.
Unlikely to change - are stable but are irregular. Terrible mechanism
for geocoding. Can we distance ourselves by saying separate service
that can do conversion?
* Allen - answer is that this is one of those issues to solve post
reference implementation events. One element in HTML has element don't
have to define - give URL but don't define. Is very loose.
* Art - anyone have better idea, one week to support it? Unless someone
proposes specific change. (Could throw this out and have FIPS tag but
is one way. Cruise with it for now and solve in 1.1. Wait for
reference implementation)
* Rex - Converter may want to look to RSS? Might want to look at it as
way to get. Art one implementation he knows that points to CAP.
[Attachments]
Art -another ongoing issue: how mechanically do we deal with audio
files, images, etc. Right now we slap in URL that points to it.
Limited from accessibility and data integrity standpoint. Started
having discussion. If asset is remote have digital digest. If want
binary to move with file have two choices:
1. SOAP with attachments (reference)
2. Code it and put it in line (include)
* Rick - Within responder community attempting to deploy standard that
will be widely acceptable. Other use case is public/public safety use
case. Are we going to make subjective decision that there will be two
use cases, one push/pull, and one push only?
* Art - large part of that is in top level alert block where you can
restrain the message. Try to be general as possible and let policy
restrict. Generally answer is both - try to be inclusive as possible.
Can we agree problem of one way links to say reference isn't sufficient?
* Brian - firewall issues shows that embedding isn't that issue.
* Art - also are bandwidth issues. May be necessary to take attachment
and strip it out and point reference to it. Point is that we want to be
able to support attachments and inline.
* Rex - WSRP submitting first spec to OASIS for approval. Way to use
registry of XML UDDI to connect up. Have option into CAP 1.0 that will
be able to have SOAP attachments. Be formulated in way to be
supportive.
* Art - are situations CAP may be used where not web services
compliant. Always treat CAP message as automic. CAP message must
always be in a SOAP message to transmit attachments. Gary - put a choice
structure in there.
* Allen - CAP has a purpose. Don't want to do everything. Streaming
CAP messages out need mechanism to stream something out behind it.
Unidirectional. If I decide CAP fits for me then there is a quality of
implementation message. Keep in mind what is quality of implementation
and what is spec issue.
* Art - this leaves it to sender to decide which format to use. May
need to general attachment process. Concern is with image and audio
blobs. How to define.
* Rick - is notification that something had happened require an
attachment?
* Art - arguable no, but number of use cases that arise in public
warning space - frequently warning messages with non- Latin character
set are rendered by poster and scan. Example, Amber Alert - want
picture of missing child
* Rick - should we do this without picture. Granularity of purpose, are
we warning or executing against warning?
* Art - One person's warning is one person's execution of warning.
* Rick - rev 1.0 say we are doing warning. Can then accommodate with
reference to attachments
* Art - identified need for attachments in rev 0.4. General
representation required
* Allen - don't expect it to be full message - its just the ALERT. Try
to extend to be more than that
* Art - info that triggers action and info that describes action.
* Rick - have to pass creation of useful information across all sizes of
pipes. Must be aware of payload extents on public network.
* Rex - have metadata in the header to reference attachments
* Gary - three types
1. alert that is internal
2. "publish" - subset of large info is provided to public knowledge --
this is what Art is calling an alert.. Subset of need to know
information.
3. full information for everyone.
* Art - CAP message needs to be reasonable automic in order to be
effective. Can't be a fragment of message. Nothing in CAP message
that goes to disposition of resources. Does have applications for
responders and non-responders alike. There is some subject matter that
where not providing for in CAP.
* Gary - attachments could be used to contain a lot more info and make
CAP into something that it isn't meant to be.
* Allen - this shouldn't be all encompassing message. We are now
starting to define how the doc is packaged. Who is receiving message?
Are they going to be able to read attachments. Need to be deployed in
infrastructure that can handle it ("heavy CAP")
* Gary - pre-negotiated options between parties - this is what will end
up happening. Can't be something that can't be dynamically managed.
* Art - bottom line do we need mechanism for moving in line or doing
purely by reference? Sounds like we are not going to get agreement to
do inline binaries, let's drop it. No one is advocating.
* Rick - do research into added payload density. What's the most
effective way to deliver message across infrastructure that exists today
to see if we can disprove the concern. Impact if we deploy the standard
in a particular way. Everything is connected - we don't control network
infrastructure that message is going to go across. Deploy a standard
that doesn't directly impact the "real world". Impacts the he
Infrastructure, device, bandwidth - all are issues Servers need to be
put in place. Is an overall infrastructure issue
* Gary - Define one standard and have another that inherits from it
* Art - technically need to have one standard. Do it by reference and
keep the message skinny
* Rick - if we deploy standard with lack of consideration on constraints
of deployment going to make an error
* David - what has been defined in version .9 has not been a problem so
let's leave out inline structure.
[Reference Implementation]
Those companies that agreed to be reference implementations include:
DMI-S - started to work
Unisys - starting to work on
Blue292 - starting to work
E Team - starting to work on
An email will be sent out to entire TC to see if anyone else is
interested in participating. Based on that determine use case to
simulate. Each of the companies are going to write the code.
* Art - What are activities of TC?
- what is use case that is going to be tested
- identify objectives (before recruiting outside company)
- define evaluation criteria
- what is architecture of reference implementation
- Agree on schedule
- Decide on type of implementation
* Art - PPW board on 29 July - how can they help - ComCARE has several
projects going on regarding CAP and would like to leverage
* Rick/Allen will build reference process - put out to committee for
comment.
+ Rick will write draft cut of this.
+ Look at all data elements
+ Push, pull or poll any of the elements id in relationship map
encompassed by specs to any of reference sites that have been identified
(polled procedures that are on schedule - no persistent handshake)
+ Evaluation done by whole committee - prove that it works
+ Example - all four send home security alert and display on each
systems identify how it worked, who it worked
* What does OASIS body do? Helping to guide us and addressing any
issues
[CAP General Items]
formal internal review - chance to look over document and comment and
cap it at one week to mark up (word doc with comments and revision) and
get info back to Art to pull together and stimulate conversation and do
final pass
[GIS]
* no update
* Question on symbology
* David - Kent State study - how has it been used and what happened to
it? David to send out response to Allen's email?
[Infrastructure Subcommittee - Rick Carlton]
Just getting into OASIS and format document of infrastructure
information into their specifications. There will be five bulletized
item in charter to respond to. After reviewing all standards realize
that the relevant standards written by MS, IBM, Oracle. Subcommittee
members had created matrix documents. Identify which standards can
apply and put matrix into structure that applies to OASIS.
[ACTION ITEMS]
* Sent email to TC to see who else wants to be reference sites for CAP
(Cathy)
* TC members who haven't reviewed CAP requirement - need to get comments
back to
Art. Closing formal review process by 31 July.
* Rick - draft of evaluation procedures
* David - send out email to TC regarding usage of Kent State symbology
study.
[NEXT MEETING]
The next meeting is a teleconference scheduled for Tuesday, 30th at
10:00am
PDT/1:00pm EDT.
--
R. Allen Wyke
Chair, Emergency Management TC
emtc@nc.rr.com
http://www.oasis-open.org/committees/emergency
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]