Title: [emergency] [#2866] Internal review, EMTC-CAP-errata
Elysa,
I have had this problem before when
converting to HTML. I believe Julia successfully made the conversion for me for
the EDXL-DE 1.0 spec. Is there someone on the TC that can handle the HTML
version for me?
Thanks,
Patti
From: Mary McRae
[mailto:]
Sent: Tue 9/19/2006 1:48
PM
To: 'Elysa Jones'
Cc:
Subject: [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:]
>
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.
IEM CONFIDENTIAL INFORMATION PLEASE READ OUR NOTICE:
http://www.iem.com/e_mail_confidentiality_notice.html
