Re: [emergency] [#2862] Public Review of HAVE

["Carl Reed OGC Account" <creed@opengeospatial.org>]

We discussed the namespace issue in the TC meeting today. This will be 
corrected. The problem is that the .xsd (and related informative document) 
are still in draft.

Thanks for your patience.

Regards

Carl

----- Original Message ----- 
From: "Mary McRae" <mary.mcrae@oasis-open.org>
To: "'Elysa Jones'" <ejones@warningsystems.com>
Cc: <emergency@lists.oasis-open.org>
Sent: Tuesday, September 19, 2006 8:33 AM
Subject: [emergency] [#2862] Public Review of HAVE


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