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

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-cap message

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


Subject: Re: [emergency-cap] CAP SC charter


Hi Steve & everybody, 

You are all free to include as much detail in the SC "charter" as you wish. However, a SC doesn't use a charter as detailed as the parent TC. That's one reason there is less detail there. To form SC, a TC merely passes a motion that includes "name, statement of purpose, list of deliverables, and name of the Chair of the SC". See https://www.oasis-open.org/policies-guidelines/tc-process#subcommittees

I just wanted to point out that difference. 

Best, 

/chet 


On Sat, Feb 28, 2015 at 5:36 PM, Steve Hakusa <shakusa@google.com> wrote:
I wasn't that familiar with the charters for other OASIS groups.  This page was helpful, as every group page has a link to its charter.  I pasted some for reference below.  Most looked more detailed than the one-line for the current CAP SC charter.  Was that on purpose?

I also pasted the scope section of the HTML working group charter, which seems to have some things in common with this group.  It has some nice language about its purpose.

Given the other charters are longer, we may want to attempt to make the phrases "ongoing maintenance" and "related work" more specific.  Possible suggestions to include in the charter:

- This subcommittee will maintain and suggest incremental revisions of the Common Alerting Protocol specification to the EM-TC.
- The subcommittee will define conformance to the CAP specification and monitor implementation via periodic surveys, workshops, or meetings.
- The subcommittee will make suggestions to the Adoption SC to update and augment CAP implementation guides.
- It is important that the communities of expertise of the respective fields (emergency managers, alert aggregators, alert disseminators) be involved in the design process.


I can try to craft this into an actual suggestion, but since this would be more than a minor edit, I wanted to hear from the group first.

Steve




https://www.oasis-open.org/apps/org/workgroup/emergency-adoption/description.php
The EM Adoption Subcommittee was created by the Emergency
Management Technical Committee (EM-TC) to assist those who wish to
implement the EM-TC's standards within software and hardware systems,
and to provide feedback to the EM-TC on implementers' experiences in
implementing those standards. 
The subcommittee will provide the following deliverables to the EM-TC:
* Update the EM-TC wiki with useful information for implementers
* Create, update and augment implementation guides for all standards
* Provide email support for EM-TC members with implementation questions
* Provide feedback to the EM-TC on implementation issues that may affect
future standards

Across the nation, government agencies, non-governmental organizations and private sector emergency management offices use the Common Alerting Protocol (CAP) for alert and warning the affected area and population. In some instances, it is necessary to constrain or extend CAP to better fit the needs and requirements of a particular system, agency, organization or country. Those constraints or extensions are described in documents known as a CAP Profile.
The purpose of this Sub Committee is to design, develop, and release XML-based standards and specifications as CAP Profiles based on the CAP Standard. 
The work products of this sub-committee will be in alignment with the rules for establishing profiles as set forth by the RIM Sub-Committee.


At any moment the "operational picture" perceived by each individual and organization represents the accumulation and fusion of various streams of incoming information. The accuracy and completeness of that operational picture, and the quality of the decisions based upon it, depend in large part on the scope, transparency and efficiency of the incoming information flows. And the effectiveness of coordinated effort among individuals and agencies depends in large part on their having access to the same flows of information (including information about each other's status and intentions) and thus sharing a common operational picture.
The EM Notification Methods and Messages Subcommittee ("the Subcommittee") will address procedures and formats for exchanging new and updated information related to functions including public safety, emergency response and homeland security. Specifically, the Subcommittee will undertake three immediate projects:
- Review and refinement of contributed work from the Common Alerting Protocol (CAP) Working Group;
- Design and development of an Incident Notification message format (which may be implemented in terms of the CAP framework or separately); and,
- Development of a core set of messages to support the National Incident Management System as mandated in Homeland Security Presidential Directive #5 (http://www.whitehouse.gov/news/releases/2003/02/20030228-9.html), based on established Incident Command System (ICS) forms (for examples, see http://216.202.128.19/dr/PDF/AppendixC.pdf).
The Subcommittee plans to advance the first of these deliverables to the full EM Technical Committee within the second calendar quarter of 2003.

This group will maintain and produce incremental revisions to the HTML specification, which includes the series of specifications previously published as XHTML version 1. Both XML and 'classic HTML' syntaxes will be produced.
The Group will define conformance and parsing requirements for 'classic HTML', taking into account legacy implementations; the Group will not assume that an SGML parser is used for 'classic HTML'.
The Group will monitor implementation of and conformance to the HTML specification, construct test suites, and from them produce interoperability reports.
The Group may hold Workshops, Interoperability Meetings, and other events as required to fulfill its mission.
Data and canvas are reasonable areas of work for the group. On the one hand, they elaborate areas touched on in HTML4. On the other hand, these elaborations are much deeper than the features of HTML4, but also they form separate subsystems, and these subsystems have strong overlaps with other design areas.
It is important that:
the design be modular;
the specifications be kept modular;
the communities of expertise of the respective fields (graphics and data) be involved in the design process.


On Thu, Feb 26, 2015 at 6:34 PM, David Askov <daskov@pdc.org> wrote:
I like Rex's idea to be a little more specific about what that means. Note that we may be working on minor-version changes (e.g.: 1.3) in parallel with major-version changes (e.g.: 2.0), so instead of "next version" (singular), we may want to say "future versions" (plural).

DAVID ASKOV | PACIFIC DISASTER CENTER | 808.891.7937 | daskov@pdc.org


-----Original Message-----
From: emergency-cap@lists.oasis-open.org [mailto:emergency-cap@lists.oasis-open.org] On Behalf Of rexbroo
Sent: Thursday, February 26, 2015 09:29
To: emergency-cap@lists.oasis-open.org
Subject: Re: [emergency-cap] CAP SC charter

I think we should make it clearly the responsibility of this SC to prepare the next version of CAP as an ongoing component of maintenance.

Suggestion: "Provides ongoing maintenance which includes preparing for the next version of the CAP standard and related work."

Cheers,
Rex

On 2/26/2015 8:47 AM, Jacob Westfall wrote:
> At the Feb 23 meeting the CAP SC charter was discussed, please see the meeting minutes.  Currently its listed as "Provides ongoing maintenance of the CAP standard and related work."  If you think the charter or the scope of the SC's work should be changed, or perhaps not changed, please submit your thoughts to the email list prior to the next meeting.  This is a good opportunity to review and clarify what the SC's role is, so please provide any input you have.

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


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php





--

/chet   [§] 
----------------
Chet Ensign
Director of Standards Development and TC Administration 
OASIS: Advancing open standards for the information society
http://www.oasis-open.org

Primary: +1 973-996-2298
Mobile: +1 201-341-1393 

Check your work using the Support Request Submission Checklist at http://www.oasis-open.org/committees/download.php/47248/tc-admin-submission-checklist.html 

TC Administration information and support is available at http://www.oasis-open.org/resources/tcadmin

Follow OASIS on:
LinkedIn:    http://linkd.in/OASISopen
Twitter:        http://twitter.com/OASISopen
Facebook:  http://facebook.com/oasis.open


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