Merge pull request #179 from apupier/fixTypos

Signed-off-by: Sander Jansen <[email protected]>

Author: Sander3003

DATABASE_MANAGEMENT.md

@@ -100,7 +100,7 @@ A Database-server-per-service pattern helps ensure that the services are lossely
 
 The CIM - IEC 61850 service for example get's their own database. If another service wants to get SCD files from this service, use the API of that particular service.
 
-### Where do we set the user privelages of Basex?
+### Where do we set the user privileges of Basex?
 Basex has it's own [User Management](https://docs.basex.org/wiki/User_Management).
 
 It's pretty straight forward: Basex has Users that can be created. These users can have so-called permissions that can be applied to the user:
@@ -109,7 +109,7 @@ It's pretty straight forward: Basex has Users that can be created. These users c
 In this overview, we see 'Global' permissions and 'Local' permissions.
 In both permission groups, a higher permission includes all lower permissions. So a user with the 'Create' permission also has the 'Read' permission.
 
-All permissions are stored in a file called users.xml (which can be editted manually) inside the database directory, and is being parsed once BaseX is started.
+All permissions are stored in a file called users.xml (which can be edited manually) inside the database directory, and is being parsed once BaseX is started.
 
 ### How do we connect BaseX with a central identity repository/application?
 BaseX doesn't have compatibility with a central identity repository (like Keycloak) out of the box available, but after discussing it with the BaseX community it's pretty comfortable to achieve this with RESTXQ or xQuery. There are examples available for making use of Keycloak:
@@ -141,7 +141,7 @@ This way it's easier to get the cause.
 ### W3 PROV
 Provenance is information about entities, activities, and people involved in producing a piece of data or thing, which can be used to form assessments about its quality, reliability or trustworthiness. The PROV Family of Documents defines a model, corresponding serializations and other supporting definitions to enable the inter-operable interchange of provenance information in heterogeneous environments such as the Web. This document provides an overview of this family of documents. (https://www.w3.org/TR/prov-overview/#Abstract)
 
-W3C does have a full standard for extending files with provenance information, in such a way that it's standardized and it enables the interchangable of provenance information in environments such as, in our case, XML environments. The design of PROV is based on the recommendations of the [Provenance Incubator Group](https://www.w3.org/2005/Incubator/prov/charter).
+W3C does have a full standard for extending files with provenance information, in such a way that it's standardized and it enables the interchangeable of provenance information in environments such as, in our case, XML environments. The design of PROV is based on the recommendations of the [Provenance Incubator Group](https://www.w3.org/2005/Incubator/prov/charter).
 
 ### W3 PROV-XML
 One of the documents of W3 PROV is PROV-XML. This document converts the PROV standard to XML definitions, and is what we want.
@@ -162,7 +162,7 @@ This is how we can interpret a edit on a XML file: as an activity.
 
 An activity has a start- and endtime. In our case, that can be the period from opening the file to saving the file. It has a type or activity, which will most of the time be an Edit.
 
-And a set of extra attributes can be added. In the added example, an hostname is added. In our case that's not very handy, because if CoMPAS is runned locally, the hostname doesn't say that much. What makes the most sense at this point is adding a User attribute which is linked to the future oAuth 2.0 authorisation/authentication module.
+And a set of extra attributes can be added. In the added example, an hostname is added. In our case that's not very handy, because if CoMPAS is ran locally, the hostname doesn't say that much. What makes the most sense at this point is adding a User attribute which is linked to the future oAuth 2.0 authorisation/authentication module.
 
 Example of added PROV section. The UserID attribute is a simplified attribute for identifying the entity doing the activity:
 ```xml

FUNCTIONAL_ARCHITECTURE.md

@@ -7,20 +7,20 @@ SPDX-License-Identifier: CC-BY-4.0
 ## Functional architecture
 
 ### Introduction
-This page desribes the functional architecture of CoMPAS. CoMPAS provides software components related to IEC 61850 model implementation, specifically for power system profile management and configuration of a power system Protection Automation and Control System (PACS). It describes the logical decomposition.
+This page describes the functional architecture of CoMPAS. CoMPAS provides software components related to IEC 61850 model implementation, specifically for power system profile management and configuration of a power system Protection Automation and Control System (PACS). It describes the logical decomposition.
 
 ### The IEC61850 standard
-The IEC61850 series are  standards and documents describing the communication protocol between different equipments in a substation. It provides services and requirements for designing and deploying substation automation. It improves power quqlity, operation cost and maintenance activities within a substation.
+The IEC61850 series are  standards and documents describing the communication protocol between different equipments in a substation. It provides services and requirements for designing and deploying substation automation. It improves power quality, operation cost and maintenance activities within a substation.
 ![CoMPAS functional block diagram](./functional-diagrams/61850flow.png)
 
 | Process | Description |
 | --- | --- |
 | **Specify IED** | With this process the Utility specifies the required IED in an ISD file. This profile is input for the manufacturer to deliver the required IED |
 | **Specify Substation System** | With this process the Utility specifies the substation system in an SSD file. For example, this specification may be done based on CIM data existing with the Utility |
-| **Configuration Substation System** | With this process the Utility configures the substation. This results in the SCD file. Aditional inputs for this process are the IID file (IED configuration) and SED file (interfacing with other projects) |
-| **Configure IED** | The process of configuring the IED. This results in an instantiated IED IID file. The process is manufacturer specific. It results in either an ICD file or IID file. It is used to convert the SCD to a manufacturer specfic CID file to be sent to the IED |
+| **Configuration Substation System** | With this process the Utility configures the substation. This results in the SCD file. Additional inputs for this process are the IID file (IED configuration) and SED file (interfacing with other projects) |
+| **Configure IED** | The process of configuring the IED. This results in an instantiated IED IID file. The process is manufacturer specific. It results in either an ICD file or IID file. It is used to convert the SCD to a manufacturer specific CID file to be sent to the IED |
 | **Test** | The fully configured IED can be tested against the SCD and SSD files |
-| **Convert CIM/GIS to IEC61850 SLD** | CIM or GIS can te used to convert to 61850 configuration files |
+| **Convert CIM/GIS to IEC61850 SLD** | CIM or GIS can be used to convert to 61850 configuration files |
 
 Refer to the [Glossary](GLOSSARY.md) for the abbreviations and various 61850 file types.
 
@@ -49,7 +49,7 @@ _**More services to be added**_
 ### Microservice architecture
 CoMPAS will consist of a number of microservices that can be used to build substation configuration tools according to IEC61850. In this situation a microservice architecture is chosen because of
 * CoMPAS will provide reusable components
-* The development will be open source, therefore by multiple development teams. Since microservices are loosly coupled and independent this will fit.
+* The development will be open source, therefore by multiple development teams. Since microservices are loosely coupled and independent this will fit.
 * Microservices are independently deployable and testable
 
 ![Microservice architecture](./functional-diagrams/microservice.png)

HIGH_LEVEL_REQUIREMENTS.md

@@ -25,7 +25,7 @@ Together with the Technical Architecture, it should be possible to make the corr
 ### IEC-61850 SCL verification
  - Conformity verification of System Configuration description Language (SCL) files
 
-### System specitifcation
+### System specification
  - profile to “System Specification Description (SSD)” conversion
  - PACS policy registry (scripts?)
  - API to vendor specific “IED Capability Description (ICD)” tools (not in direct scope, Nice To)

ISSUE_MANAGEMENT.md

@@ -5,10 +5,10 @@ SPDX-License-Identifier: CC-BY-4.0
 -->
 
 ## Issue Management
-For issue management we are using the issue tracker in Github. Issues are created in the repository where there are related to.<br/>
+For issue management we are using the issue tracker in GitHub. Issues are created in the repository where there are related to.<br/>
 Issues that concern the whole CoMPAS project are added as issue in the repository "compas-architecture". Later these maybe be move to the correct repository.  
 
-To get an overview of all the issues we are using the project board in Github.
+To get an overview of all the issues we are using the project board in GitHub.
 There are two overview board on organisation level to monitor all the issues and pull request in the different repositories.
 One for the issues, CoMPAS Issues Overview Board and one for the pull requests, CoMPAS Pull Request Overview Board.
 Every repository that can contain issues and pull request are linked to these two project boards.
@@ -39,8 +39,8 @@ Now we need to link the new repository to both Project Boards. Repeat the follow
 Don't open the board, but under "..." (end of row) select "Settings". Next go to "Linked repositories" and link the new repository using the button "Link a repository".
 the repository is now shown in the list of linked repositories.Now it's possible to also added issues and pull request to the board.
 
-### Add Github Action 
-To automatically adding issues and pull request to a project board we add a github action for that. 
+### Add GitHub Action 
+To automatically adding issues and pull request to a project board we add a GitHub action for that. 
 In the repository create a file "automate_projects.yml" in the directory ".github/workflows" containing the following source code: 
 
 ```yaml
@@ -81,7 +81,7 @@ jobs:
           GITHUB_PROJECT_URL: https://github.com/orgs/com-pas/projects/2 #(3)
           GITHUB_PROJECT_COLUMN_NAME: To do
 ```
-The github action exists of 4 steps. 
+The GitHub action exists of 4 steps. 
 - (Step 1): Add new issues to the project board of the repository.
 - (Step 2): Add new pull requests to the project board of the repository.
 - (Step 3): Add new issues to the organisation project board "CoMPAS Issues Overview Board".
@@ -115,7 +115,7 @@ Project board "CoMPAS Pull Request Overview Board":
 |                              | Pending approval by reviewer                |                                                    |
 
 ### Adding Action Secret ORG_GITHUB_ACTION_SECRET
-Tot access the project boards of the organization a secret ORG_GITHUB_ACTION_SECRET needs to be created.
+To access the project boards of the organization a secret ORG_GITHUB_ACTION_SECRET needs to be created.
 - First create a new personal access token from https://github.com/settings/tokens. Tokens can only be created as personal tokens.
   The token also must have the right "admin:org". This will indirectly also set the right "write:org" and "read:org". 
 - Next create a new organisation secret from https://github.com/organizations/com-pas/settings/secrets/actions with the value of 

README.md

@@ -14,22 +14,22 @@ This site provides the architectural description of CoMPAS. It describes the [Fu
 General information about CoMPAS can be found [on the wiki at the LFE site](https://wiki.lfenergy.org/display/HOME/CoMPAS).
 
 ## Open Community Calls
-We hold an open community call on the first Monday of every month (always check the calender). The start time right now is:
+We hold an open community call on the first Monday of every month (always check the calendar). The start time right now is:
 
 3:00pm - 4:00pm CET
 
-If you wish to participate, please join the [CoMPAS mailing list](https://lists.lfenergy.org/g/CoMPAS). Or contact us in the slack #compas channel on (public/LFEnergy-slack.svg)](http://lfenergy.slack.com/)/
+If you wish to participate, please join the [CoMPAS mailing list](https://lists.lfenergy.org/g/CoMPAS). Or contact us in the slack #compas channel on [public LFEnergy slack](http://lfenergy.slack.com/)/
 
 The schedule for the next calls can be found in the mailing list [calendar](https://lists.lfenergy.org/g/CoMPAS/calendar).
 If you want to subscribe and stay up to date about upcoming events, consider subscribing to the [CoMPAS mailing list](https://lists.lfenergy.org/g/CoMPAS).
 
 ## Contributing
 Interested in contributing? Please read carefully the [CONTRIBUTING guidelines](https://com-pas.github.io/contributing/).
 
-## Github Pages
-This site is provided as a [github pages site](https://com-pas.github.io/compas-architecture/). 
-The content is maintained and edited on [Github](https://github.com/com-pas/compas-architecture). 
-Contributors are only allowed to contribute by editing the content on Github and must do so by presenting their modifications as *pull-request* to the community. 
+## GitHub Pages
+This site is provided as a [gitHub pages site](https://com-pas.github.io/compas-architecture/). 
+The content is maintained and edited on [GitHub](https://github.com/com-pas/compas-architecture). 
+Contributors are only allowed to contribute by editing the content on GitHub and must do so by presenting their modifications as *pull-request* to the community. 
 The diagrams on this page are created using [DrawIO](https://github.com/jgraph/drawio-desktop/releases) 
 and follow [Unified Modeling Language (UML)](https://www.omg.org/spec/UML/). 
 The drawIO design file is available on this site: [/blob-files/CoMPAS.drawio](blob-files/CoMPAS.drawio). 

TECHNOLOGY.md

@@ -25,7 +25,7 @@ Microservices are deployed as Linux based Docker container. Advantages of deploy
 
 - Deployment is independent of deployment platform/OS
 - Well supported for cloud deployment
-- Tooling readily availabe
+- Tooling readily available
 - Open source
 - Scalable, redundant
 - Images can be distributed easily
@@ -140,17 +140,17 @@ Because CoMPAS is an application which also should run locally, memory usage is
 - Relatively new technology, framework could contain some "rookie mistakes". On the other hand, multiple researches are stating the maturity of the framework it achieved in this short time.
 - Not many developers are acquainted with Quarkus compared to e.g. the [Spring framework](https://spring.io/).
 
-## Source control - Github
-We choose github for source control. This is good practice for open source development. 
+## Source control - GitHub
+We choose GitHub for source control. This is good practice for open source development. 
 The CoMPAS repositories can be found at [https://github.com/com-pas/](https://github.com/com-pas/) 
 
-## CI/CD - Github actions
-We choose [Github Actions](https://github.com/features/actions) as mechanism for CI/CD. 
+## CI/CD - GitHub actions
+We choose [GitHub Actions](https://github.com/features/actions) as mechanism for CI/CD. 
 
 **Pros**
 - Upcoming tool, really active in developing
-- Free tool for public Github repositories (which CoMPAS is)
-- Integrates perfectly with Github repositories
+- Free tool for public GitHub repositories (which CoMPAS is)
+- Integrates perfectly with GitHub repositories
 
 **Cons**
 - Software is proprietary
@@ -159,8 +159,8 @@ We choose [Github Actions](https://github.com/features/actions) as mechanism for
 
 
 # Tool advise
-This section lists the development tooling that is *advised*. Of course developers are free to use their own developement tooling
+This section lists the development tooling that is *advised*. Of course developers are free to use their own development tooling
 
 ## SDE - Microsoft Visual Studio Code
-[Microsoft Visual Studio Code](https://code.visualstudio.com/) is a versatile develpment environment supporting many languages. 
+[Microsoft Visual Studio Code](https://code.visualstudio.com/) is a versatile development environment supporting many languages. 
 

technical/TECHNICAL_ARCHITECTURE.md

@@ -18,15 +18,15 @@ The diagram above shows the deployment view. Blue components are within scope of
 
 The result of the CI/CD is a **Container Image** in the Docker Registry. A **Container Image** contains one **CoMPAS microservice**. More than one CoMPAS microservice may be present in the image only if they are closely related and should be deployed and scaled together.
 
-As part of the CI/CD proces a security scan is performed on the source code. The **Container Image**s must be signed and are the formal deliveries of the CoMPAS project.
+As part of the CI/CD process a security scan is performed on the source code. The **Container Image**s must be signed and are the formal deliveries of the CoMPAS project.
 
-In the deployment proces the **Container image** is deployed together with its dependencies (for example a database) in an **Application**. This deployment takes place using *Docker Compose*. For this a **docker compose yaml** file is supplied that deploys the application using Docker Compose.
+In the deployment process the **Container image** is deployed together with its dependencies (for example a database) in an **Application**. This deployment takes place using *Docker Compose*. For this a **docker compose yaml** file is supplied that deploys the application using Docker Compose.
 
 Generally speaking, it is a good idea to deploy one thing per container. Reasons:
 * Independent scaling: APIs scale differently than databases
 * Independent update: update in isolation
 * Supports different environments: a containerized database locally while managed service in production
-* No need for a process magager
+* No need for a process manager
 
 
 Third party microservices can be incorporated in an end user application or can be required for CoMPAS microservices, 
@@ -38,7 +38,7 @@ Deployment is done by the users of CoMPAS and out of scope for the project.
 Below describes the current deployment view of the CoMPAS containers that are available.
 This view will be updated during time to add the new components that are build.
 
-![CoMPAS Deploment View](images/CoMPAS-DeploymentView.png)
+![CoMPAS Deployment View](images/CoMPAS-DeploymentView.png)
 
 The user uses a browser to open the OpenSCD editor from the CoMPAS OpenSCD Container. In this editor there are plugins
 available to use the XML REST Services from CoMPAS to open, save and validate SCL files or use a mapper to converted