[#2862] Public Review of HAVE

["Mary McRae" <mary.mcrae@oasis-open.org>]

Hi Elysa,

There's some problems with the submission - Jamie actually review the document
so it's his notes below. Please also note that there's a problem with the schema
and the use of a namespace referenced as "www.oasis-org.org" and "geo-oasis" --
if this is an OGC schema, then it should have an OGC namespace and must be
accessible, per our rules. OASIS namespaces cannot be assigned to work that is
not the work of an OASIS committee and must be referenced by the appropriate
issuing organization.

It's a long list - my apologies. Items are noted below.

Regards,

Mary


-----Original Message-----
> From: Elysa Jones [mailto:ejones@warningsystems.com] Sent:
> Monday, September 11, 2006 12:36 PM To: Mary McRae Cc: Julia Ridgely; 
> Sukumar Dwarkanath Subject: HAVE - 60 Day Public Comment
> 
> 
> Hey Mary, The EM-TC is proud to announce that we are ready to go for 
> public comment on the Hospital AVailability Exchange Draft.
> The following links include what you should need. If there is 
> something missing, please let me know.

> 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
> 

   Not OK yet.  We need to confirm that the version that was uploaded was the
one approved.
   The 22 August recorded minutes shows votes to approve the then-current draft,
which would have been doc 19704 uploaded on 13 August. The TC appears to have
correctly approved the doc below, as a CD and for PR.  Approvals were unanimous
(and included 6 or more of the committee's 11 voting members). Nothing wrong
with these voting mechanics. But the doc has been *changed* since the vote.
   Doc 19704 looks similar to the proposed PR version (doc 20149), other than
appropriate header changes AND the items listed in the attached table, which
seem not to have been approved. (Simply because they postdate the known
meeting.)  Would the TC please verify in writing that the editor's changes in
20149 were approved by the TC.  We noted that some material changes to the text,
and apparently to the XML schemas themselves, were included.  We assume that
requires the TC's assent.

> 2. PDF of the document. 
> http://www.oasis-open.org/apps/org/workgroup/emergency/download.php/20
> 150/emergency_edxl_have-1.0-spec-pr-01.pdf
> 

   PDF document OK. Cursory comparison to the .DOC below shows only some
insignificant formatting differences, noted below.

> 3. HTML of the document. 
> http://www.oasis-open.org/apps/org/workgroup/emergency/download.php/20
> 151/edxl%20have%20public%20review%20HTML.zip
> 

   OK, subject to defects in XHTML compliance deemed tolerable for now.
   The incorporated image files appear to be present and correctly associated
with main HTML text document. Cursory comparison to the .DOC and .PDF files show
no significant differences (other than, e.g., obvious omission of footer).
   Our rules require the use of XHTML, but what we have instead points to and
implements HTML 4.01, with some XHTML characteristics.  Other aspects violate
the XHTML spec.  However, it's our assumption that this document was converted
into XHTML, not natively created in XHTML.  Assuming that the omissions (wrong
format namespace, no DOCTYPE declaration, empty-element violations, etc.) 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 copy of the document. 
> http://www.oasis-open.org/apps/org/workgroup/emergency/download.php/20
> 149/emergency_edxl_have-1.0-spec-pr-01.doc
> 

   The Microsoft Word document is OK, but there are flaws which the editor
should be given a chance to correct, given that other changes
are required.

   This doc is the version used in the prior-draft comparison noted in #1 above.
We assume this is the source document, in which case that requirement is met.

    An error in section numbering (two sections "3.2.6", and no section
"3.2.7") seems to persist across all formats.  Please correct.

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,

    {{ Our templates ([1], below) require that both a "current" 
location
and a "this version" location are listed in the front page metadata.
The named location "docs.oasis-open.org/emergency/EDXL-HAVE/V1.0"  is an
adequate "current" location.  Please add a "this version" URI specific to the
present draft.  We suggest considering the concatenation of the "current
location" and the unique part of the artifact identifiers, i.e.:

"docs.oasis-open.org/emergency/EDXL-HAVE/V1.0/edml_have-1.0-spec-pr-01"

However, there are several possibilities. Please see the OASIS Naming Guidelines
at [2] for more information.

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

}}

> 
> and must include the OASIS copyright notice.

     The supplied notice is not correct.  It should be revised when the
corrected document is submitted.
     The TC currently operates under our Legacy IPR Policy, but the editor
inserted the 2005 IPR Policy form of copyright notices.  If this were an
otherwise compliant draft, we would regard this as a harmless error in a PR
draft, as (a) it will resolve itself effective upon their pending transition;
(b) Section 4(D) of the Legacy policy does not apply here, and (c) using the
newer policy test instead of the old one does not materially change or reduce
the relevant requirements in the context of a preliminary review.
     If the doc is corrected or revised prior to the effective IPR transition
date for the TC, this must be corrected.  The correct notice can be found in the
templates [2] with names referring to the
   "Legacy IPR Notice".

     The copyright notice incorrectly is dated 2005 instead of 2006 (or 2005-06
if the drafting began last year).  Please correct in next revision.

Editor: ComCare is an Associate Member (basically an individual membership) and
therefore not eligible to have their name on the cover of the spec. It should
say: Sukumar Dwarkanath, Associate Member.

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

     See [1] for the templates.  Compliance OK.  Font and text formatting
compliance generally seems correct, for a public review.
Template issues about the stated file location metadata are noted above.  Some
of the XHTML template aspects also are incorrect, including ToC structure and
CSS use, but as noted above, we assume this is a tool limitation.  The TC may
wish to consider cleaning up some of the unnecessary elements in the finalized
specification,

  Note that "wsrf" is included in the ipr link (status section) rather than
"emergency". 

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

       Not OK.  List is present.  We assume that it was properly circulated.
Some individual/associate members have their corporate affiliation listed; they
are not corporate members and therefore must be listed as "Associate Member".
They include:
.	Greg Meyer*, iJet International, Inc.*
.	Sukumar Dwarkanath*, COMCARE*
.	John Moehrke*, GE Healthcare*
.	Adam Hocek*, Broad Strokes, Inc.*
.	Winfield Wagner*, Crossflo Systems, Inc.*
.	Michelle Raymond*, Honeywell*
.	Mark Carlson*, Conneva, Inc.*

> 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. There is apparent compliance with this rule. See Secs. 1.3 &
1.4 of the spec.

> 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.
> 
> 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 notes above, but we
did not receive separate schema files (see below), so this is not robustly
tested.

> All expressions must be valid.

      No flaws immediately noted, but we did not receive separate schema files
(see below), so this is not robustly tested.

> 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, subject to clarification (see above) of whether this version is a
second CD different from the first approved CD.

Please reply back to our official and logged notice address for spec submissions
at tc-admin@oasis-open.org.  We appreciate the TC's efforts and would be happy
to discuss the foregoing, if your editors or members have any questions.

Report-20149vs19704.odt