Difference between revisions of "V3 PubProcess - Submit Content"
| Line 2: | Line 2: | ||
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. | 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: | |
| + | ::1.2.1 ZIP the content for submission | ||
| + | ::1.2.2 Delete the "submission content" from the directories | ||
| + | ::1.2.3 ZIP the remaining "unused content" into a second ZIP archive | ||
| + | ::1.2.4 Delete the "unused content from the directories (leaving the ZIP behind) | ||
| + | ::1.2.5 Extract the "submission content" to repopulate the directories | ||
| + | :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 or are already part of the desktop publishing process. | 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 or are already part of the desktop publishing process. | ||
Revision as of 00:21, 18 September 2010
Contents
01...Content Submission
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:
- 1.2.1 ZIP the content for submission
- 1.2.2 Delete the "submission content" from the directories
- 1.2.3 ZIP the remaining "unused content" into a second ZIP archive
- 1.2.4 Delete the "unused content from the directories (leaving the ZIP behind)
- 1.2.5 Extract the "submission content" to repopulate the directories
- 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 or are already part of the desktop publishing process.
The manifest from this review will produce either a ZIP file of all content or a file list that may be automatically applied to SVN to extract the desired content. (Current 7/21/10 capability is only the ZIP file.) Once the package is assembled it needs to be "placed" (either Gforge or SVN) where the recipient of the submission can use it.
01.20...Notify (if to HQ)
When the submission is packaged, HQ needs to be notified, if this is a submission or a ballot or a Normative Edition.
01.30...Version and Download
The recipient will extract the submission and assure that it is properly placed in the SVN system for the publication being prepared.
01.40...Acknowledge (if HQ)
The final step, in the case of a submission to HQ, will be the return of an acknowledgment to the submitter.
