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

[Rex Brooks <rexb@starbourne.com>]

It's that darn diagram again. It is supposed to be included 
unchanged, but every time any document in which it is included is 
transferred, up or down, it appears to have a 50-50 chance of 
becoming unreadable. This happened before I worked on a file that 
included it, as well as after. I can assure you, I did absolutely 
nothing to the diagram one way or the other in any of the files I 
changed because there was no reason to touch it. The only changes, 
outside of date and document name were to add one line to the 
included xml schema file.

This kind of thing can happen a number of different ways as it 
traverses the web stacks on both ends, but when such a situation 
occurs with a document I have uploaded, it is difficult to 
troubleshoot since I use Windows XP Pro on a couple of machines, 2000 
Pro on one, RedHat Enterprise Linux on another and a Mac OSC 10.3 on 
another, and to be honest, I don't recall which machine I used, and 
that can make all the difference or no difference whatever. Another 
consideration is that the diagram appears fine in one program on one 
machine and is unreadable on a different machine in a different 
program, such as Open Office v. Windows Office 2003, or AdobeReader 
v. another pdf reader. It's the nature of the exercise. Sorry for 
whatever part of this is my doing.

Regards,
Rex

At 2:48 PM -0400 9/19/06, Mary McRae wrote:
>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.


-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309