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: FW: [emergency] [#2866] Internal review, EMTC-CAP-errata


The CAP 1.1 Errata review from 9/19/2006.

Patti Iles Aymond, PhD 
Senior Scientist, Research & Development 
Innovative Emergency Management, Inc.
Managing Risk in a Complex World

8555 United Plaza Blvd.   Suite 100 
Baton Rouge, LA 70809 
(225) 952-8228 (phone) 
(225) 952-8122 (fax) 

-----Original Message-----
From: Mary McRae [mailto:mary.mcrae@oasis-open.org] 
Sent: Tuesday, September 19, 2006 1:48 PM
To: 'Elysa Jones'
Cc: emergency@lists.oasis-open.org
Subject: [emergency] [#2866] Internal review, EMTC-CAP-errata
Importance: High

Hi Elysa,

  There's some problems with the submission - Jamie actually review the
document
so it's his notes below. 


Regards,

Mary 


-----Original Message-----
> From: Elysa Jones [mailto:ejones@warningsystems.com]
> Sent: Monday, September 11, 2006 3:25 PM
> To: Mary McRae
> Cc: Julia Ridgely; Aymond, Patti
> Subject: CAP 1.1 Errata
> 
> Hey Mary,
> The following links are submitted for the public review period for the

> CAP 1.1 errata:

> Thanks! Elysa
> 
> 1. Approved meeting notes where the TC decided to make this a 
> Committee Draft and also advance it to Public Comment.
> http://www.oasis-open.org/apps/org/workgroup/emergency/download.php/20
> 127/Approved%20Meeting%20Notes%208-22-2006.doc
> 

   Process: Not OK yet. The 22 August recorded minutes shows votes to
approve
the then-current draft uploaded by Rex Brooks, which would have been doc
19870
uploaded on 22 August.
    The TC appears to have correctly approved the doc below as a CD, and
did
vote to commence a PR. But to approve a PR in order to support proposed
"Approved Errata" status, under the rule in TCP Section 3.5, requires
the TC to
vote on three propositions:  the two above,
*plus* a vote to "[c]onfirm ... by Full Majority Vote that the proposed
corrections do not constitute a Substantive Change."  That conclusion
could have
been part of a single vote with the other two, but it does not appear in
the
minutes.  Would the TC please confirm in writing that it reached that
conclusion
(i.e., by correcting the minutes) or, if it has not yet reached that
conclusion,
please confirm it in a new vote and advise us.

   Fidelity of approval of revision: OK. Doc 19870 looks generally
identical to
Doc 20245, delivered to us as as the proposed PR version.
except in appropriate places where metadata or spec status info should
be, and
have been, revised. However, please note the new filename and "Abstract"
issues
on the front page, as described below.

   Fidelity of errata: OK. Doc 19870, which the TC approved as proposed
errata,
is in the form of the full spec as-changed by the proposed errata. The
errata
itself is stated compactly in doc 19868.
Hypothetically this should have been applied to the final approved OS
v1.1,
which is doc 15134 dated 1 Nov 2006. We also ran a blackline between the
.DOC
versions 15134 and 19870 to confirm this, and noted
that:
   -- The UML-like illustration in Section 3.1 present in the Nov.
2005 OS spec is deleted from the errata. (However, it appears clear that
the TC
intended the diagram to remain, and the diagram was included in doc
20245,
except in the HTML as noted below.)
   -- The revision history in Appendix C does not note the new proposed
errata
change. (Its last entry is dated 27 July 2005.)  However, this was
corrected in
doc 20245.
   -- The approved change stated in doc 19868 does appear to be
correctly fixed
in line 339 of doc 19870 (the XML schema in Section 3.4).

> 2. PDF Doc.
> http://www.oasis-open.org/apps/org/workgroup/emergency/download.php/20
> 246/CAPv1-1Errata.pdf
>

   PDF document OK. Cursory comparison to the .DOC below shows no
significant
formatting differences. 

> 
> 3. HTML Doc.
> http://www.oasis-open.org/apps/org/workgroup/emergency/download.php/20
> 247/CAPv1.1Errata.html
>

   Not OK.    .
   Cursory comparison to the .DOC and .PDF files show no significant
differences
except as noted below.
   However, the incorporated image file (UML-like illustration in
Section 3.1)
appears to be missing from the HTML version. The designated download URI
supplies only the base HTML document and no image. Probably should be
packaged
with the image file(s) and the base HTML document in a zip.
   Also, while our rules also require the use of XHTML, we note that
this
document instead points to and implements HTML 4.01, with some XHTML
characteristics.  Other aspects violate the XHTML spec (wrong format
namespace,
no DOCTYPE declaration, empty-element violations, etc.).
However, it's our assumption that this document was converted into
XHTML, not
natively created in XHTML.  Assuming that the omissions are a tool
limitation,
we believe they should be accepted, for now.  As better XHTML tools
become
widely available, this practice may change.

> 4. Word Doc. 
> http://www.oasis-open.org/apps/org/workgroup/emergency/download.php/20
> 245/CAPv1-1Errata.doc
> 
> Please let me know if there is anything more you need. Thanks!
> Elysa

    The Microsoft Word document is OK, but there is a flaw which the
editor
should be given a chance to correct, given that other changes are
required.
   This doc is the version used in the comparisons noted above. We
assume this
is the source document, in which case that requirement is met.
    

Looking to another source of requirements, our spec quality rule says:

> 2.18 Specification Quality
> 
> All documents and other files produced by the TC, including 
> specifications at any level of approval, must use the OASIS file 
> naming scheme,

{{ Not OK. Two exceptions noted:
   -- The Microsoft Word and PDF document file names as uploaded are
"CAPv1-1Errata.doc" and "CAPv1-1Errata.pdf" but the [X]HTML version name
is
"CAPv1.1Errata.html". Note the difference between character separators.
Filename
must be the same for all three, and the filename and ID metadata list on
page
one of all three formats of the spec must be identical to each other
(excluding
format extensions such as ".pdf").
   -- The "location" metadata inaccurately names a URI which includes
the
document ID ".../14205/..."  This refers to an earlier version, and is a
private
URI (not accessible to the public);  both flaws must
be corrected in any case.   We suggest you consider updating
this to a URI in the docs.oasis-open,.org domain (see below) but, at a
minimum,
it must point to a current and public URI that includes the proposed
errata.
   -- Related matters are discussed below under "templates". }}

> and must include the OASIS copyright notice.

   Not OK. The TC currently is under the Legacy IPR Policy, and the
spec's
copyright notice text (on page 2) faithfully copies it (as did the 2005
OASIS
Standard), except for a typo, *but* it significantly omits a section
required by
Section 4(D) of the legacy policy:

>> Where, pursuant to a notification under this Policy, the OASIS Board 
>> of Directors is aware at the time of publication of proprietary 
>> rights claimed with respect to an OASIS specification, or the 
>> technology described or referenced therein, such specification shall 
>> contain the following notice:
>> "OASIS has been notified of intellectual property rights claimed in 
>> regard to some or all of the contents of this specification. For more

>> information consult the online list of claimed rights."

There are such claims posted against CAP (see
http://www.oasis-open.org/committees/emergency/ipr.php), so the
additional 4(D)
text above must be added under the applicable version of our policy.
(Unless
the IPR Mode conversion of this TC is effective before the public review
starts.)

   Because the spec must be revised, please also fix the typo: The word
"may"
should be substituted for the word "does" in this
sentence: " ... However, this document itself does not be modified in
any way,
such as by removing ..."

>
> All document files must also use the OASIS document templates.

   Not OK.  Font and text formatting compliance generally seems correct,
for a
public review.  {{ However:
   -- Our spec templates [1] require that both a "current" location and
a "this
version" location are listed in the front page metadata.
We suggest adopting the use of the docs.oasis-open.org subdomain at this
point,
in which case appropriate values could be (for example):
   "This version: docs.oasis-open.org/emergency/CAP/V1.1/cap-1.1-os-02"
   "Current: docs.oasis-open.org/emergency/CAP/V1.1"
However, there are several possibilities. Please see the OASIS Naming
Guidelines
at [2] for more information.
   -- The templates also require a "previous" entry where applicable --
this is
relevant to an errata print.  The front page metadata also should
include:
   "Previous version:  [URI of approved OS standard]"

   -- The 'Status' metadata paragraph needs modification.  This text is
left
over from the 2005 OS, unchanged.  It should be amended to add a
sentence at the
end, stating that this is proposed 2006 errata for the 2005 v1.1
standard.  It
also should add this notation from the published template (relevant to
items
going out for review):

>> Technical Committee members should send comments on this 
>> specification to the Technical Committee's email list. Others should 
>> send comments to the Technical Committee by using the "Send A 
>> Comment" button on the Technical Committee's web page at 
>> www.oasis-open.org/committees/[TC short name] .

[1] http://docs.oasis-open.org/templates/
[2]
http://docs.oasis-open.org/specGuidelines/namingGuidelines/resourceNamin
g.html 


  }}

> The name of any specification may not include any trademarks or 
> service marks not owned by OASIS.

   OK.  No apparent violations.

> A specification that is approved by the TC at any level must include a

> list of people who participated in the development of the 
> specification. This list shall be initially compiled by the Chair, and

> any Member of the TC may add or remove their names from the list by 
> request.

   OK.  List is present.

> A specification that is approved by the TC at any level must clearly 
> indicate whether each reference in the specification to a document or 
> artifact is a Normative Reference.

   OK.  While there's some doubt whether this new rule should apply to
errata to
an old spec, this document apparently complies in any case.  See its
Sec. 1.6.

> Editable formats of all versions of TC documents must be submitted to 
> the TC's document repository. TC Working Drafts may be in any format 
> (i.e. produced by any application).

   OK.  We assume the Microsoft Word version is intended to satisfy this
requirement.
> 
> All TC-approved versions of documents (i.e. Committee Drafts, Public 
> Review Drafts, and Committee Specifications) must be submitted to the 
> TC's document repository in the editable source, XHTML, and PDF 
> formats. Any links published by the TC shall be to the XHTML and/or 
> PDF formats stored in the TC's document repository.

   All docs are properly in the doc repository (although not all
correctly
references on the spec front page, as noted above).
> 
> All schema and XML instances, whether by inclusion or by reference, 
> including fragments of such, must be well formed.

   No flaws immediately noted EXCEPT for the XHTML rules noted above,
but we did
not receive separate schema files (see below), so not robustly tested.
This was,
however, approved as an OASIS standard previously, with only one
(unremarkable)
change in one line in the schema.  So we rely on the prior compliance
check for
this.

> All expressions must be valid.

   No flaws immediately noted, but we did not receive separate schema
files (see
below), so not robustly tested.  This was, however, approved as an OASIS
standard previously, with only one (unremarkable) change in one line in
the
schema.  So we rely on the prior compliance check for this.

> All machine-processable schemas, XML instances etc. that are part of 
> the specification must be available separately in their own plain text

> file with their own file name.

   Not OK.  No separate schema text files were delivered.  This is an
important
requirement for evaluators and implementers, easily remedied, and should
be
produced by the TC.

> A specification may be composed of any number of files of different 
> types, though any such multi-part specification must have a single 
> specification name and version number. Irrespective of the number and 
> status of the constituent parts, the specification as a whole must be 
> approved by a single TC ballot.

   OK.  Rule not apparently applicable here.

> Any change made to a specification requires a new version or revision 
> number, except for changes made to the title page and in the running 
> footer noting the approval status and date, which must be made after 
> the approval of the specification.

    OK.



IEM CONFIDENTIAL INFORMATION PLEASE READ OUR NOTICE:
http://www.iem.com/e_mail_confidentiality_notice.html



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