This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "V3 PubProcess - Submit Content"

From HL7Wiki
Jump to navigation Jump to search
 
(5 intermediate revisions by the same user not shown)
Line 1: Line 1:
 +
__NOTOC__
 +
<strong><big>Primarytargets and documentation on this page</big></strong>
 +
*[[#01.10...Review Quality and Prepare Manifests |01.10...Review Quality and Prepare Manifests ]]
 +
*[[#01.20...Package Active and Support Content for Submission |01.20...Package Active and Support Content for Submission ]]
 +
{{:V3PubProcessTargetNotation}}
 +
 
==01...Content Submission==
 
==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.
 
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.
Line 4: Line 10:
 
The steps include:
 
The steps include:
 
:1.1 Create a QA report and a manifest of all of the files needed to "publish" the specification.
 
: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 Once the manifest is built, use it to build a submission package and reduce domain files to only those required for publication
::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.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.4 (By HQ) Download the appropriate files and acknowledge receipt.
Line 20: Line 21:
 
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 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 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.
  
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.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...Notify (if to HQ)===
+
===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.
 
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 ===
+
===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 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.40...Acknowledge (if HQ)===
+
===01.50...Revert to Prior Content===
The final step, in the case of a submission to HQ, will be the return of an acknowledgment to the submitter.
+
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.  
  
 
{{to-top}}
 
{{to-top}}
 +
 +
{{:ToPublishingProcessRoot}}
 +
 +
----

Latest revision as of 02:47, 30 September 2010

Primarytargets and documentation on this page

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:
  • Primary targets are shown on this page in bold face; they correspond to "batch" files of the same name.
  • Supplemental targets are shown on this page indented and in normal font; they correspond to "batch" files named with the prefix "supp-" followed by the target name.

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

Jump to top of page

Jump to Publishing Process "Root" Page