diff --git a/.github/workflows/generate-pdf.yml b/.github/workflows/generate-pdf.yml
deleted file mode 100644
index 7aaaf3b..0000000
--- a/.github/workflows/generate-pdf.yml
+++ /dev/null
@@ -1,35 +0,0 @@
-name: Generate PDF
-on:
- release:
- types: [published]
-jobs:
- build:
- runs-on: ubuntu-latest
- steps:
- - env:
- ENABLE_PDF_EXPORT: 1
- - uses: actions/checkout@v2
- - uses: actions/setup-python@v2
- with:
- python-version: 3.x
- - run: pip install mkdocs-material
- - run: sudo apt install libpango-1.0-0 libharfbuzz0b libpangoft2-1.0-0
- - run: pip install mkdocs-pdf-export-plugin
- - run: mkdocs build
- - uses: actions/upload-artifact@v3
- with:
- name: CIM Modeling Guide PDF
- path: site/CIM Modeling Guide.pdf
- release:
- runs-on: ubuntu-latest
- permissions:
- contents: write
- needs: build
- steps:
- - uses: actions/download-artifact@v3
- with:
- name: CIM Modeling Guide PDF
- path: CIM Modeling Guide.pdf
- - uses: ncipollo/release-action@v1
- with:
- artifacts: "CIM Modeling Guide.pdf"
\ No newline at end of file
diff --git a/README.md b/README.md
index 4c24b5a..576da38 100644
--- a/README.md
+++ b/README.md
@@ -22,18 +22,3 @@ For Python, do `pip install mkdocs-material` then once installed, the basic comm
* `mkdocs -h` - Print help message and exit.
Once you have it running with either Docker or Python, you can view it by navigating to http://localhost:8000 on your browser.
-
-## PDF Generation
-A PDF copy of the CIM Modeling Guide is created using an `mkdocs` plugin called [`pdf-export`](https://github.com/zhaoterryy/mkdocs-pdf-export-plugin). To generate the PDF on Windows, install GTK runtime found [here](https://github.com/tschoonj/GTK-for-Windows-Runtime-Environment-Installer/releases). See [Weasyprint documentation](https://doc.courtbouillon.org/weasyprint/stable/first_steps.html#installation) for other platforms such as Linux.
-
-Then install the plugin
-```cmd
-pip install mkdocs-pdf-export-plugin
-```
-
-Finally, set the following environment variable and run the build
-```cmd
-set ENABLE_PDF_EXPORT=1
-mkdocs build
-```
-The PDF will appear in the build output
\ No newline at end of file
diff --git a/docs/images/media/image12.png b/docs/images/media/image12.png
new file mode 100644
index 0000000..c15464d
Binary files /dev/null and b/docs/images/media/image12.png differ
diff --git a/docs/index.md b/docs/index.md
index a8b1319..4ef768c 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -1,4 +1,4 @@
-![](images/media/image1.png)
+
**UCAIug**
diff --git a/docs/section4-cim-overview.md b/docs/section4-cim-overview.md
index 2d94e93..e966916 100644
--- a/docs/section4-cim-overview.md
+++ b/docs/section4-cim-overview.md
@@ -78,7 +78,7 @@ The CIM UML is semantic information model that represents real-world physical el
CIM Management is a business function performed by the CIM Subcommittee of the UCAIug Technical Oversight Committee (see Figure 4‑1).
-![](images/media/image2.jpeg)
+
Figure 4‑1. UCA International Users Group Organization Chart
@@ -152,7 +152,8 @@ Continuous process improvement (CPI) is the ongoing process of improving the CIM
Mapping of the CIM management functions includes two (2) mappings of the CIM management functions. The first shows the mapping between CIM management functions and CIM management responsibilities assigned to the CIM Subcommittee with the UCAIug. The second shows the mapping between CIM management functions and the CIM management processes that realize those functions. The first mapping is shown in Figure 4‑2. The second mapping is discussed in Section 4.4 and shown in Figure 4‑9
-![](images/media/image3.png)
+
+
Figure 4‑2. CIM Management Functions-to-UCA CIM Responsibilities Mapping
@@ -178,7 +179,7 @@ CIM management processes are the realization of CIM management functions. There
Figure 4‑4. Model Development Process Flow
-![](images/media/image6.png)
+
Figure 4‑5. Change Management Process
@@ -198,7 +199,7 @@ CIM management processes are the realization of CIM management functions. There
The mapping between CIM management functions and the CIM management processes are shown in Figure 4‑9.
-![](images/media/image10.png)
+
Figure 4‑9. CIM Management Process-to-CIM Management Functions Mapping
@@ -206,13 +207,13 @@ The CIM Model Managers perform most of the tasks within the CIM management proce
| **Role** | **Role Description** | **MDP** | **CMP** | **DGP** | **ADP** | **CPIP** |
|----------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------|---------|---------|---------|----------|
-| CIMug Focus Community | This group role consists of individual CIMug members and IEC CIM Working Group members dedicated to developing CIM extensions that deal with a specific area of focus. | ✓ | | | | |
-| CIMug Project Team | This group role consists of individual CIMug members and IEC CIM Working Group members working on projects that are jointly funded by participating utilities or vendor companies. | ✓ | | | | |
-| CIMug Working Group | This group role consists of individual CIMug members working on issues of common interest to CIM Users. | ✓ | | | | |
-| IEC CIM Working Group | This group role consists of individuals appointed by their respective IEC National Committee (technical experts) that take part in the drafting of IEC standard working documents. | ✓ | | ✓ | | |
-| IEC Working Group Project Leader | This individual role performed by an IEC Working Group member has overall responsibility for leading the development of a new edition of an international standard from the IEC proposal stage through to the IEC publication stage. | ✓ | | ✓ | | |
-| IEC Working Group Convener | This individual role performed by an IEC Working Group member is responsible for arranging and leading face-to-face IEC Working Group meetings and providing working group oversight. | | ✓ | | | ✓ |
-| Model Manager | This individual role performed by an individual that is a member of both the CIMug and an IEC Working Group has overall responsibility for artifacts under CIM management. | ✓ | ✓ | ✓ | ✓ | ✓ |
+| CIMug Focus Community | This group role consists of individual CIMug members and IEC CIM Working Group members dedicated to developing CIM extensions that deal with a specific area of focus. | | | | | |
+| CIMug Project Team | This group role consists of individual CIMug members and IEC CIM Working Group members working on projects that are jointly funded by participating utilities or vendor companies. | | | | | |
+| CIMug Working Group | This group role consists of individual CIMug members working on issues of common interest to CIM Users. | | | | | |
+| IEC CIM Working Group | This group role consists of individuals appointed by their respective IEC National Committee (technical experts) that take part in the drafting of IEC standard working documents. | | | | | |
+| IEC Working Group Project Leader | This individual role performed by an IEC Working Group member has overall responsibility for leading the development of a new edition of an international standard from the IEC proposal stage through to the IEC publication stage. | | | | | |
+| IEC Working Group Convener | This individual role performed by an IEC Working Group member is responsible for arranging and leading face-to-face IEC Working Group meetings and providing working group oversight. | | | | | |
+| Model Manager | This individual role performed by an individual that is a member of both the CIMug and an IEC Working Group has overall responsibility for artifacts under CIM management. | | | | | |
Table 4‑3. Role-to-CIM Management Process Mapping
@@ -284,10 +285,10 @@ A mapping between the applicable IEC standards development stages and the CIM Ma
| | Proposal Stage | Preparatory Stage | Committee Stage | Enquiry Stage | Approval Stage | Publication Stage |
|-------------------------------|-------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------|
-| Model Development Process | ✓ | ✓ | ✓ | ✓ | ✓ | |
-| Change Management Process | ✓ | ✓ | ✓ | ✓ | ✓ | |
-| Document Generation Process | | | ✓ | ✓ | ✓ | |
-| Artifact Distribution Process | | ✓ | ✓ | ✓ | ✓ | ✓ |
+| Model Development Process | | | | | | |
+| Change Management Process | | | | | | |
+| Document Generation Process | | | | | | |
+| Artifact Distribution Process | | | | | | |
#### 4.5.2.1 Draft Standards Preparation
diff --git a/docs/section5-cim-uml-modeling-rules-and-recommendations.md b/docs/section5-cim-uml-modeling-rules-and-recommendations.md
index 4c6811a..2921e45 100644
--- a/docs/section5-cim-uml-modeling-rules-and-recommendations.md
+++ b/docs/section5-cim-uml-modeling-rules-and-recommendations.md
@@ -87,11 +87,11 @@ The top-level "CIM" (formerly TC57CIM) package is partitioned into sub-packages
Both the legacy and new top-level package structure are shown in Figure 5‑1 and Figure 5-2 respectively.
-![](images/media/image13.png)
+
Figure 5‑1 - TC57CIM Package Structure
-![](images/media/image13-new.png)
+
Figure 5‑2 - CIM Package Structure (New)
@@ -213,7 +213,7 @@ Types used for attributes in a class introduce dependencies that must be coordin
-![](images/media/image14.png)
+
Figure 5‑3. Top-level CIM (formerly TC57CIM) Package Dependencies
@@ -221,7 +221,7 @@ Types used for attributes in a class introduce dependencies that must be coordin
Each working group edits what it owns and merges what others own. With three working groups this results in six possible ways to exchange portioned model files between the groups as shown in Figure 5-4.
-![](images/media/image15.png)
+![](../images/media/image15.png)
Figure 5-4 - Possible partition file exchanges between WG13, WG14 and WG16
@@ -239,7 +239,7 @@ The procedure to update a package with a partition file corresponds to an arrow
To properly obtain the correct UML package versions in a synchronized model, one can follow the steps in Figure 5-5. Complete synchronisation can be achieved by copying whole models as shown in Figure 5-5.
-![](images/media/image16.png)
+![](../images/media/image16.png)
Figure 5-5 Complete synchronisation example
diff --git a/docs/section6-cim-uml-extension-rules-and-recommendations.md b/docs/section6-cim-uml-extension-rules-and-recommendations.md
index 17bd3d9..7e233f1 100644
--- a/docs/section6-cim-uml-extension-rules-and-recommendations.md
+++ b/docs/section6-cim-uml-extension-rules-and-recommendations.md
@@ -22,7 +22,7 @@ It is recommended to utilize existing data types and CIM classes where possible.
The typical case of adding a new extension class and associating with existing standard classes is can be modeled in a diagram within the extension package as shown in Figure 10 Example UML model for extension class with association to standard class. This situation does not require multiple inheritance.
-![](images/media/image17.png)
+
Figure Example UML model for extension class with association to standard class
@@ -38,13 +38,13 @@ The new attributes or associations can be added to the new extension class and t
A new attribute is effectively added to an existing CIM class within the new extension package using a diagram within the extension package as shown in Figure 11 Example UML model for attribute extensions to standard CIM classes.
-![](images/media/image18.png)
+
Figure Example UML model for attribute extensions to standard CIM classes.
A new association can be effectively between two standard CIM classes by introducing one of the classes as an extension class in the extension package then making the association to the other class. There is no guidance on which end to chose as the extension class and it may be driven by having already added one of the extension classes to the extension package for other purposes. A diagram in the extension package can be used as shown in Figure 12 Example UML model for association extensions to standard CIM classes. If both classes are already extension classes, the association should be added between the two extension classes for better modularity.
-![](images/media/image19.png)
+
Figure Example UML model for association extensions to standard CIM classes
@@ -210,15 +210,15 @@ Inherited association ends should have unique names.
| Rule203 | Inherited association ends shall have unique role names. |
| Rule204 | Associations between CIM extension classes and high-level standard CIM classes should be minimized. |
-![](images/media/image20.png)
+
Figure 6‑1. Example of two associations between two classes
-![](images/media/image21.png)
+
Figure 6‑2. Example of self-association
-![](images/media/image22.png)
+
Figure 6‑3. Allowed duplication of association end names
diff --git a/mkdocs.yml b/mkdocs.yml
index a852f21..44d00cc 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -16,12 +16,6 @@ markdown_extensions:
- admonition
- tables
- pymdownx.details
-plugins:
- - search
- - pdf-export:
- enabled_if_env: ENABLE_PDF_EXPORT
- combined: true
- combined_output_path: CIM Modeling Guide.pdf
nav:
- 'index.md'
- 'section1-introduction.md'