RE: [emergency] [#2866] Internal review, EMTC-CAP-errata

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/resourceNaming.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.

emergency message