MHonArc v2.4.5 -->
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.
http://www.oasis-open.org/committees/process.php#approval_spec
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.
Ciao,
Rex
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)
csubatch@eteam.com
Tel: 510-849-2309
Fax: By Request
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]