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 20: Line 20:
 
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 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.
 +
 
 +
:'''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 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 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.)
  
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)===
 
===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.
 
When the submission is packaged, HQ needs to be notified, if this is a submission or a ballot or a Normative Edition.

Revision as of 01:22, 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:
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 manifest an be used in subsequent steps to isolate the submitted content and "hide" the unused content in ZIP archives.

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

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.

Jump to top of page