Updated icd docs (manually)

Author: abrighton

idbs/3.3.0/idbs/overview.html

@@ -176,15 +176,15 @@ <h1><a href="#overview" name="overview" class="anchor"><span class="anchor-link"
 <p>The components of the Interface Database System are shown below. They are briefly described here, with more details provided in subsequent sections.</p>
 <p>The workflow proceeds from left to right.</p>
 <p><img src="../images/overview/fig1.jpg" /></p>
-<p>The TIO developer, using Common Software for his/her components, creates component model files. These files are validated and ingested into the ICD Model File Database using either the <code>icd-db</code> command or a web application called <code>icdwebserver</code>. These were developed to work with the ICD Model File Database and provide the functionality the users of the system need. The model files are stored and published in Git repositories on GitHub. The <code>icd-git</code> application can be used to sync the local database with the published versions on GitHub. The icd web app also gets its information from the published versions on GitHub, in addition to any unpublished versions that a developer is working with locally. The <code>icd-viz</code> command line application can be used to generate a graph of component or subsystem relationships. This feature requires that <a href="https://graphviz.org/">graphviz</a> is installed and is also available in the icd web app. The <code>icd-fits</code> command can be used to view information about FITS keywords and their source events.</p>
+<p>The TIO developer, using Common Software for his/her components, creates component model files. These files are validated and ingested into the ICD Model File Database using either the <code>icd-db</code> command or a web application called <code>icdwebserver</code>. These were developed to work with the ICD Model File Database and provide the functionality the users of the system need. The model files are stored and published in Git repositories on GitHub. The <code>icd-git</code> application can be used to sync the local database with the published versions on GitHub. The icd web app also gets its information from the published versions on GitHub, in addition to any unpublished (uploaded) versions that a developer is working with locally. The <code>icd-viz</code> command line application can be used to generate a graph of component or subsystem relationships. This feature requires that <a href="https://graphviz.org/">graphviz</a> is installed and is also available in the icd web app. The <code>icd-fits</code> command can be used to view information about FITS keywords and their source events.</p>
 <h2><a href="#icd-db" name="icd-db" class="anchor"><span class="anchor-link"></span></a>icd-db</h2>
 <p>The <code>icd-db</code> program exists to validate and ingest model files into a local ICD Model File Database. When creating or modifying the models, this feature can be used to incorporate working versions of the files into the database system. The <code>icd-db</code> program also allows some informative queries to be performed directly on the database, showing what subsystem and components exist in the database, and information about them such as data rates, data types, and units used. Note that these operations only work on the models that exist in the local version of the database, and do not access the released models on the GitHub repository.</p>
 <h2><a href="#icdwebserver" name="icdwebserver" class="anchor"><span class="anchor-link"></span></a>icdwebserver</h2>
 <p>The <code>icdwebserver</code> web application provides the IDBS user application interface. The browser-based user interface allows the ingesting of model files, publishing them, and displaying versioned APIs for each component. An API is defined as all the functionality of a component or subsystem including inputs and outputs. An ICD is produced by taking the intersection of two subsystem API documents.</p>
 <p>The IDBS browser provides the ability to browse the APIs for both published and unpublished models. The published APIs are constructed from models obtained from the git repository which stores the released versions, and the unpublished APIs are constructed by accessing the models stored in the local database that have been ingested using the icd-db program or the web app.</p>
 <p>The current version of the IDBS browser user interface includes the following features:</p>
 <ul>
-  <li>Allows browsing all the subsystems and their components (including previously published versions as well as unpublished working versions).</li>
+  <li>Allows browsing all the subsystems and their components (including previously published versions as well as uploaded, unpublished working versions).</li>
   <li>View the API for a subsystem or an individual component.</li>
   <li>Browse interfaces between subsystems, or components within subsystems.</li>
   <li>Upload directories containing the model files for a subsystem API</li>

idbs/3.3.0/images/webapp/apsApi.png

@@ -190,7 +190,7 @@ <h2><a href="#upload-files" name="upload-files" class="anchor"><span class="anch
 <p>If the web server is running on your own machine, go to <a href="http://localhost:9000">http://localhost:9000</a>. The empty website is shown in the following figure. The upload button is shown circled in red (the red circle does not appear in the UI!)</p>
 <p><img src="../images/webapp/uploadFiles.png" /></p><div class="callout note "><div class="callout-title">Note</div>
 <p>The icd web app automatically ingests the most recently released APIs and ICDs on startup by downloading any missing versions from the GitHub repos under <a href="https://github.com/tmt-icd">https://github.com/tmt-icd</a>. Older versions of APIs are downloaded from GitHub and ingested automatically as needed. You can preload the local database to include all versions of the subsystem APIs using the icd-git command line app before starting the icd web app: <code>icd-git --ingestAll</code>.</p>
-<p>You can also upload any directories containing model files that you are working on. These will be the considered the “working version” or “*” in the subsystem version menu. The &quot;*&quot; version is either the last version uploaded, or the latest published API version, if there was no uploaded version, or if a more recent version was published (Note: This may change in a future release to be only the uploaded version). </p></div>
+<p>You can also upload any top level directories containing subsystem API model files that you are working on. These will be the considered the &ldquo;uploaded&rdquo; or working version (&ldquo;uploaded&rdquo; in the subsystem version menu).</p></div>
 <h2><a href="#procedure-for-uploading-files" name="procedure-for-uploading-files" class="anchor"><span class="anchor-link"></span></a>Procedure for Uploading Files</h2>
 <ol>
   <li>Select the upload button in the web app. The following figure shows the web page after selecting the upload button:</li>
@@ -218,8 +218,8 @@ <h2><a href="#view-a-subsystem-api" name="view-a-subsystem-api" class="anchor"><
 <p><img src="../images/webapp/apsApi.png" /></p>
 <p>A couple of things to note: The area to the left shows a number of links. This area has one link for each component in the subsystem.</p>
 <p>The content area displays all the components for the subsystem. Clicking on one of the component links jumps to the given component’s information.</p>
-<p>The displayed API is constructed from the current versions of the models in the database, and is therefore considered an unpublished working version. Although APIs are published by Systems Engineering, the system allows the viewing of all versions of published APIs as well as the working version as shown above (Note: the published versions of the APIs are ingested directly from the GitHub repository, whereas the unpublished models are obtained only from the local database). To do this, select the desired version number in the dropdown menu next to the subsystem name.</p>
-<p>Note that “master” also appears in the list of versions and is linked to the contents of the master branch of a subsystem on GitHub. The contents of the master branch are automatically uploaded to the icd database (if there was a change) whenever you refresh the web app or when running the command: <code>icd-git --ingest</code>.</p>
+<p>The displayed API is constructed from the current versions of the models in the database. Although APIs are published by Systems Engineering, the system allows the viewing of all versions of published APIs as well as uploaded (working versions) as shown above (Note: the published versions of the APIs are ingested directly from the GitHub repository, whereas the unpublished (uploaded) models are obtained only from the local database). To do this, select the desired version number in the dropdown menu next to the subsystem name.</p>
+<p>Note that “master” also appears in the list of versions and is linked to the contents of the master branch of a subsystem on GitHub. The contents of the master branch are automatically uploaded to the icd database (if there was a change) whenever you select &ldquo;master&rdquo; in one of the subsystem menus.</p>
 <p><img src="../images/webapp/tcsSelectVersion.png" /></p>
 <p>There are two checkboxes in the Select dialog that are only enabled for APIs (when only one subsystem is selected).</p>
 <ul>
@@ -244,13 +244,13 @@ <h2><a href="#view-api-history" name="view-api-history" class="anchor"><span cla
 <p><img src="../images/webapp/history.png" /></p>
 <h2><a href="#create-and-view-an-icd" name="create-and-view-an-icd" class="anchor"><span class="anchor-link"></span></a>Create and View an ICD</h2>
 <p>An ICD is formed by taking the intersection of the APIs of two TMT subsystems. That means in order to create an ICD there must be at least two subsystems in the database. The TCS API is created from various subsystem to TCS ICDs that exist and the TCS CODR SDD. The definitive TCS API will be a product of the TCS work packages.</p>
-<p>It is possible to view ICDs with working/unpublished versions, with one unpublished version and one published version, or two published versions. ICDs can only be published between two published APIs.</p>
+<p>It is possible to view ICDs with uploaded (working/unpublished) versions, with one unpublished version and one published version, or two published versions. ICDs can only be published between two published APIs.</p>
 <p>This example will show how to view a working ICD between the published version 1.12 of the TCS API and the unpublished M1CS subsystem API.</p>
 <ol>
   <li>
   <p>Upload all the working versions of the APIs needed to form an ICD.</p></li>
   <li>
-  <p>First select the version of the subsystem for the ICD. In the figure below the menu to the right of the subsystem shows the available versions. Version 1.12, the version published previously is selected. (To get back to the working version, select the asterisk in the menu.) Note that the content area says API for TCS 1.12 rather than the unpublished label.</p></li>
+  <p>First select the version of the subsystem for the ICD. In the figure below the menu to the right of the subsystem shows the available versions. Version 1.12, the version published previously is selected. (To get back to the uploaded working version, select &ldquo;uploaded&rdquo; in the menu.) Note that the content area says API for TCS 1.12 rather than the &ldquo;uploaded&rdquo; label.</p></li>
 </ol>
 <p><img src="../images/webapp/select-tcs-m1cs-icd.png" /></p>
 <ol>

idbs/3.3.0/images/webapp/generateButton.png

@@ -176,15 +176,15 @@ <h1><a href="#overview" name="overview" class="anchor"><span class="anchor-link"
 <p>The components of the Interface Database System are shown below. They are briefly described here, with more details provided in subsequent sections.</p>
 <p>The workflow proceeds from left to right.</p>
 <p><img src="../images/overview/fig1.jpg" /></p>
-<p>The TIO developer, using Common Software for his/her components, creates component model files. These files are validated and ingested into the ICD Model File Database using either the <code>icd-db</code> command or a web application called <code>icdwebserver</code>. These were developed to work with the ICD Model File Database and provide the functionality the users of the system need. The model files are stored and published in Git repositories on GitHub. The <code>icd-git</code> application can be used to sync the local database with the published versions on GitHub. The icd web app also gets its information from the published versions on GitHub, in addition to any unpublished versions that a developer is working with locally. The <code>icd-viz</code> command line application can be used to generate a graph of component or subsystem relationships. This feature requires that <a href="https://graphviz.org/">graphviz</a> is installed and is also available in the icd web app. The <code>icd-fits</code> command can be used to view information about FITS keywords and their source events.</p>
+<p>The TIO developer, using Common Software for his/her components, creates component model files. These files are validated and ingested into the ICD Model File Database using either the <code>icd-db</code> command or a web application called <code>icdwebserver</code>. These were developed to work with the ICD Model File Database and provide the functionality the users of the system need. The model files are stored and published in Git repositories on GitHub. The <code>icd-git</code> application can be used to sync the local database with the published versions on GitHub. The icd web app also gets its information from the published versions on GitHub, in addition to any unpublished (uploaded) versions that a developer is working with locally. The <code>icd-viz</code> command line application can be used to generate a graph of component or subsystem relationships. This feature requires that <a href="https://graphviz.org/">graphviz</a> is installed and is also available in the icd web app. The <code>icd-fits</code> command can be used to view information about FITS keywords and their source events.</p>
 <h2><a href="#icd-db" name="icd-db" class="anchor"><span class="anchor-link"></span></a>icd-db</h2>
 <p>The <code>icd-db</code> program exists to validate and ingest model files into a local ICD Model File Database. When creating or modifying the models, this feature can be used to incorporate working versions of the files into the database system. The <code>icd-db</code> program also allows some informative queries to be performed directly on the database, showing what subsystem and components exist in the database, and information about them such as data rates, data types, and units used. Note that these operations only work on the models that exist in the local version of the database, and do not access the released models on the GitHub repository.</p>
 <h2><a href="#icdwebserver" name="icdwebserver" class="anchor"><span class="anchor-link"></span></a>icdwebserver</h2>
 <p>The <code>icdwebserver</code> web application provides the IDBS user application interface. The browser-based user interface allows the ingesting of model files, publishing them, and displaying versioned APIs for each component. An API is defined as all the functionality of a component or subsystem including inputs and outputs. An ICD is produced by taking the intersection of two subsystem API documents.</p>
 <p>The IDBS browser provides the ability to browse the APIs for both published and unpublished models. The published APIs are constructed from models obtained from the git repository which stores the released versions, and the unpublished APIs are constructed by accessing the models stored in the local database that have been ingested using the icd-db program or the web app.</p>
 <p>The current version of the IDBS browser user interface includes the following features:</p>
 <ul>
-  <li>Allows browsing all the subsystems and their components (including previously published versions as well as unpublished working versions).</li>
+  <li>Allows browsing all the subsystems and their components (including previously published versions as well as uploaded, unpublished working versions).</li>
   <li>View the API for a subsystem or an individual component.</li>
   <li>Browse interfaces between subsystems, or components within subsystems.</li>
   <li>Upload directories containing the model files for a subsystem API</li>