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
Line 4: Line 4:
 
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 15:
 
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 manifest from this review will produce manifest an be used in subsequent steps to isolate the submitted content and "hide" the unused content in ZIP archives.
+
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):
 
:'''Defined Processes''' (Eclipse '''''Target''''' or '''''BAT''''' file):
:*'''''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 builds QA preview in '''''Generator/OutputFiles/Reports''''', and defines the resulting manifest for all domains in '''''Generator/TemporaryFiles/specificManifests'''''.
+
:*'''''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.20...Package Active-Support Content for Submission'''''' Processes the domains listed as 'active' and 'support' for submission.  For each domain, this includes '''all of the steps listed under 1.2 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.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 of the steps listed under 1.2 above'''.
 
:*'''''01.50...Revert Active and Support Content'''''' Re-extracts the 'unused' content for the 'active' and 'support' domains from the final 'unused' ZIP archive for the current date. For now, extracting for an earlier date can be done manually, or the script must be started with the "extractionDate" property set to the desired string. (Methodology not currently documented.)
 
  
===01.20...Notify (if to HQ)===
+
===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.
===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 final step, in the case of a submission to HQ, will be the return of an acknowledgment to the submitter.
 +
:'''Defined Processes''' (Eclipse '''''Target''''' or '''''BAT''''' file):
 +
:*'''''01.50...Revert Active and Support Content''''' Re-extracts the 'unused' content for the 'active' and 'support' domains from the final 'unused' ZIP archive for the current date. For now, extracting for an earlier date can be done manually, or the script must be started with the "extractionDate" property set to the desired string. (Methodology not currently documented.)
  
 
{{to-top}}
 
{{to-top}}

Revision as of 02:32, 18 September 2010

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.

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.

Defined Processes (Eclipse Target or BAT file):
  • 01.50...Revert Active and Support Content Re-extracts the 'unused' content for the 'active' and 'support' domains from the final 'unused' ZIP archive for the current date. For now, extracting for an earlier date can be done manually, or the script must be started with the "extractionDate" property set to the desired string. (Methodology not currently documented.)

Jump to top of page