FW: [ws-rx] AI #0057 - Editors will report on the mailing list those procedures they use before posting a WD

Gil,

 

I am wondering whether we should add steps for 
incorporating each issue as the agreed resolution gets incorporated to a wd in 
addition to the posting a WD. 

 

-- This step is not part of the wd posting to the team, 
but E assumes that each person indicates the resolved issue in the description 
field. It may be beneficial to record the assumption for completeness (I am 
aware that everyone is following this implicit step already in recording 
resolutions) so that we could replicate this process in another TC. 

 

-- We also have the procedure that the wd 
revisions are kept by adding revisions to a specific draft number. This is again 
implied by post publishing tasks, but not explicit F as we agreed to those in 
separate threads in updating a specific draft within the editor's team. 

 

I do not expect someone else to volunteer to become an 
editor in this tc at this stage and learn all this. However, it would be 
beneficial to gather the general procedures outlined for BOTH working with wd 
and publishing the drafts to the tc so that we could replicate it somewhere 
else. 

 

Makes sense? 

 

Thanks. 

 

--umit

 

From: Gilbert Pilz [mailto:] 

Sent: Thursday, Jan 12, 2006 12:55 PM
To: 

Subject: [ws-rx] AI #0057 - Editors will 
report on the mailing list those procedures they use before posting a 
WD

 Here's the procedures.

 

  

  
Check and verify schema and WSDL 
files

The 
following XML documents are maintained separately from the specification 
documents:

  

  
wsrm-1.1-schema-[yyyymm].xsd

  

  
wsrm-1.1-wsdl-[yyyymm].wsdl

  

  
wsrmp-1.1-schema-[yyyymm].xsd

Verify 
that each of these documents is both well-formed and a valid instance of its 
type (XML Schema, WSDL, etc.). The editors are encouraged to co-ordinate the 
various tools (oXygen, XMLSpy, etc.) used to validate these documents to avoid a 
monoculture with regards to validation. In other words, different tools should 
be used to prevent the creation of implementation specific bugs within these 
documents.

If a 
document is not well-formed or fails to validate use your best judgment on how 
to address the issue. Minor corrections and omissions can be fixed immediately. 
Changes in function or semantics should be addressed via an issue in the 
Technical Committee.

  

  
Generate Clean PDF

  
    

    
Import and format linked sections. This can 
    be done by either having the correct files in place (c:\temp) when you open the document, or later by 
    invoking “Tools->Update->Update All”. To format the linked text select 
    the text and apply the “Code” style.

    

    
Regenerate Table of Contents.

    

    
Check current document.

    
      

      
check document version on title page

      

      
check “Document identifier”

      
        

        
title page

        

        
footers

      

      
check date

      
        

        
title page

        

        
footers

      

      
check Revision History against list of 
      known changes

    

    
Pick any one of 3 different ways to 
    generate the PDF. Double check your file/arifact name before you hit the OK 
    button.

  

  
Generate PDF With Change 
  Bars

  
    

    
Accept all changes in the 
    current document “Edit->Changes->Accept or Reject”. Once you have done 
    this you need to be careful to never check the resulting history-less 
    version of the document back into Kavi under the current “stage” and 
    “revision” (e.g. wd-08). This history-less version will form the base of the 
    next version of this document (see step (F.1)).

    

    
Download the previous 
    source-format version of your current document.

    

    
Accept all changes in the 
    previous version of the document and save this file. Once you have done this 
    you need to be careful to never check the resulting history-less version of 
    the document back into Kavi. Your local copy of the previous version is now 
    a temporary document to be used solely for the purposes of generating the 
    correct change bars.

    

    
From within the current 
    document compare the current document to the previous version of the 
    document (“Edit->Compare Document”). With changes showing generate a PDF. 
    Remember to add “-diff” to the file/artifact name.

  

  
Review PDFs With 
  Editors

Distribute 
the PDFs created in steps (B) and (C) amongst the editorial team and solicit 
feedback. Time permitting, editorial issues should be fixed immediately (return 
to step (B)). Larger issue should be addressed through the TC process. Repeat 
steps (B) through (D) until the editorial team concurs that the documents are 
fit to publish.

  

  
Publish the PDFs on the Main 
  TC Page

The 
current folder for working drafts is “Editors Drafts” and the current folder for 
committee drafts is “Committee Drafts”.

It is 
helpful to copy the “Description” field from the latest copy of the 
source-format version. This allows people that are looking for the changes 
resulting from a particular issue to more easily find the draft version that 
incorporated those changes without having to open multiple drafts.

  

  
Post Publishing Tasks

  
    

    
Rename the history-less 
    version of the current document to the next working draft increment (e.g. 
    wd-08 becomes wd-09, cd-02 becomes wd-10).

    

    
Upload the new working 
    document into Kavi under the “Calendar Documents” folder. Make sure to name 
    the document in Kavi appropriate to its Stage, Revision, and Form (e.g. 
    wsrm-1.1-spec-wd-09.odt).

    

    
Move the old working 
    document from the “Calendar Documents” folder to the “Closed Editors Drafts” 
    folder.