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


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

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

Subject: Re: [emergency] CAP Validation Testing

Title: Re: [emergency] CAP Validation Testing
Hi Everyone,

As a heads-up in regard to this we should be careful to distinguish between an unofficial request for public comment, which is part of the open, public OASIS TC Process at all times through the public-comment email facility and which I am assuming this is (with a bit more of an announcement), and the official OASIS public comment period for a Technical Committee Specification that has been approved as a "Committee Specification." As such, I also think this document should be identified as a "Working Draft."

This official public comment period is mandated by a 2/3 majority vote for approval by the full TC and which then, as required by the OASIS TC Process, can decide by a simple majority vote to have the Committee Specification undergo a public review of at least 30 days and is announced by OASIS through Karl Best. The 30-day minimum Public Comment Period and any subsequent amendments to the specification are required before a specification can be submitted for OASIS-wide approval.


Just thought I'd better make sure this is clear. At present there is no mandated secondary process for advancing a subcommittee deliverable to the wider TC.

Now for my preliminary thoughts.

I think the preferred term for mandatory elements is "required."  At least that's what I've seen. It could be that I simply haven't seen examples of "mandatory." I don't have a preference.

I would put the data dictionary into an appendix at the end and include it in the document repository as a separate file for easier access. I would put each item in its own section number with its standard schema coding and with an implementation note or example in the specification document itself and not include the .xsd file within the specification. I would have the .xsd file separate in the namespace document repository directory for the TC's specifications because that's how it needs to be accessed from the standard OASIS urn, eventually...(Sigh, this is not yet standard across standards bodies, but we can hope it works out that way.)

I make all those suggestions on the basis of both experience of building and writing specs and the necessity of building primer/userguides/tutorials and/or APIs from them and it is just easier to copy and paste that way than in either the schema file or a table. (I will be working on the Primer for the WSRP Spec this summer, and the spec itself is 86 pages, so making things easier to adapt is one of those things I pay real close attention to when I could end up having to adapt it.)

Otherwise, hurrah! Looks good to me.


At 7:13 PM -0700 7/17/03, CSubatch@eteam.com wrote:
At Tuesday's EM TC meeting in Virginia, Art Botterell presented the results on the work the Notifications, Messaging and Methods subcommittee has done with CAP.  As Art noted, the CAP document is in final review for comments.   Please send any comments to the Art and the subcommittee at emergency-msg@lists.oasis-open.org
The document is posted at http://www.oasis-open.org/committees/documents.php?wg_abbrev=emergency-msg

At the meeting Blue292, E Team, DMI-S, and Unisys volunteered to participate in testing the CAP alert notification standard.  If your organization is interested in participating in this testing (testing criteria are currently being developed), please send me an email and I will coordinate with the appropriate parties.  Thank you.

Cathy M. Subatch
E Team Inc.
818.932.0660 x248
310.770.6885 (mobile)

Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request

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