V3 PubProcess - Submit Content
Primarytargets and documentation on this page
- 01.10...Review Quality and Prepare Manifests
- 01.20...Package Active and Support Content for Submission
|This page documents a number of named ANT "targets" (names like 00.10...REVIEW properties) that invoke specific tasks, and documents. The combined publishing tools include ten "primary" targets, and over 25 "supplemental" targets. These are distinguished as follows:
This section encompasses those steps undertaken by a Publishing Facilitator (or other person preparing part or all of a publication package) in order to assemble and "submit to publishing" their specific portion of the content. Note that in this context, "submit to publishing" means either to submit to HQ for publishing or to "submit" to oneself for local publishing.
The steps include:
- 1.1 Create a QA report and a manifest of all of the files needed to "publish" the specification.
- 1.2 Once the manifest is built, use it to build a submission package and reduce domain files to only those required for publication
- 1.3 Version the resulting file set in SVN and notify HQ of its availability (if appropriate)
- 1.4 (By HQ) Download the appropriate files and acknowledge receipt.
- 1.5 Revert to previous content.
Note: The two ZIP archives for each specification are distinguished by name and an appended date string (like uvct-Unused_20100917). There is also a "re-extraction" process that will allow one to "automatically" re-extract the file content from the current or an earlier date.
01.10...Review Quality and Prepare Manifests
The initial step in the publishing process is to identify those files that are required for publication. For a "domain" the entire required content can be determined from the Publication data base for the domain. For a specification submitted as "free-hand" documentation, the content must be determined by "inspection" of the source files. While automated processing of the "Pub XML" can identify all required content, this capability has not yet been extended to the other publications.
The challenge are the artifacts, image files, model files, etc. that must be collected to publish the document. The automated process tracks the references from the primary document, attempts to determine that the targets of those references exist, and then produces a file manifest that can be used to assemble a ZIP file of the content for submission.
The first step will be to extract the primary document (in the case of a domain it is extracted from the publication database), and analyze this document for its references. Transforms to accomplish this are already part of the desktop publishing process. The manifest from this review can be used in subsequent steps to isolate the submitted content and "hide" the unused content in ZIP archives.
- 01.10...Review Quality and Prepare Manifests Extracts the content from all PubDbs found in the databases subdirectory of all domains; uses the Generator to build a QA preview in Generator/OutputFiles/Reports, and defines the resulting manifest for all domains in Generator/TemporaryFiles/specificManifests.
01.20...Package Active and Support Content for Submission
Once the manifest is built, it can be used to build a submission package and to reduce the domain files to only those required for publication. Specific steps that are followed include
- 01.21 ZIP the content for submission
- 01.22 Delete the "submission content" from the directories
- 01.23 ZIP the remaining "unused content" into a second ZIP archive
- 01.24 Delete the "unused content" from the directories (leaving the ZIP behind)
- 01.25 Extract only the "submission content" to repopulate the directories
- Defined Processes (Eclipse Target or BAT file):
- 01.20...Package Active-Support Content for Submission Processes the domains listed as 'active' and 'support' for submission. For each domain, this includes all five of the steps listed above.
- 01.29...Extract and Package - Combines 01.10 and 01.20 - Extracts the content from all PubDbs; rebuilds the manifests and then processes the domains listed as 'active' and 'support' for submission. For each domain, this includes all five of the steps listed above.
01.30...Version and Notify
When the submission is packaged, HQ needs to be notified, if this is a submission or a ballot or a Normative Edition.
01.40...Download and Acknowledge
The recipient will extract the submission and assure that it is properly placed in the SVN system for the publication being prepared. The final step, in the case of a submission to HQ, will be the return of an acknowledgment to the submitter.
01.50...Revert to Prior Content
The dual archives for "submission" and "unused" content permit one to roll back the input file structures to what they were before the domain was packaged. This is the process step that supports such reversion.
- Defined Processes (Eclipse Target or BAT file):
- 01.50...Revert Active and Support Content - This process starts with a prompt to enter the date string on which the archive(s) for this domain were created. these strings are part of the archive file name and are formatted like 20100929. Once entered, the process will process all domains on the "active" and "support" lists looking for archives with that date string. If it finds the archives, it will delete all other files from that domain, including sub-directories, and then will extract both the "submission" and "unused" archives, thereby restoring the content to what it had been before packaging.