OASIS Emergency Management TC

 View Only

Meeting Minutes: 2003.07.15 (delayed)

  • 1.  Meeting Minutes: 2003.07.15 (delayed)

    Posted 10-07-2003 02:59
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    emergency message

    [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]