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