Fix some typos in documentation.

docs/conf.py

@@ -51,4 +51,4 @@
 
 # -- Options for sphinx.ext.todo ---------------------------------------------
 # https://www.sphinx-doc.org/en/master/usage/extensions/todo.html
-todo_include_todos = True
+todo_include_todos = True

docs/index.rst

@@ -10,7 +10,7 @@ Pure Python OPC-UA / IEC 62541 Client and Server for Python 3.7+ and pypy.
 
 OPC-UA implementation is quasi complete and has been tested against many different OPC-UA stacks. API offers both a low level interface to send and receive all UA defined structures and high level classes allowing to write a server or a client in a few lines. It is easy to mix high level objects and low level UA calls in one application.
 
-Most code is autogenerated from xml specification using same code as the one that is used for freeopcua C++ client and server, thus adding missing functionnality to client and server shoud be trivial.
+Most code is autogenerated from xml specification using same code as the one that is used for freeopcua C++ client and server, thus adding missing functionality to client and server should be trivial.
 
 - Some documentation is available at http://opcua-asyncio.readthedocs.org/en/latest/
 - A simple GUI client is available: https://github.com/FreeOpcUa/opcua-client-gui

docs/usage/common/node-nodeid.rst

@@ -8,7 +8,7 @@ The NodeId Class
 :class:`asyncua.ua.uatypes.NodeId` objects are used as unique ids for :class:`~asyncua.common.node.Node`'s
 and are therefore used on the server and client side to access specific nodes. The two classes 
 :class:`~asyncua.ua.uatypes.NodeId` and :class:`~asyncua.common.node.Node` should not
-be confused: The NodeId is the unique identiefier of an actual Node. While the NodeId is used to identify
+be confused: The NodeId is the unique identifier of an actual Node. While the NodeId is used to identify
 a specific node, the Node object can be used to access the underlying data.
 To learn more about the Node class, head over to :ref:`usage/common/node-nodeid:the node class`.
 
@@ -19,14 +19,14 @@ In addition there is the :attr:`~asyncua.ua.uatypes.NodeId.NodeIdType` attribute
 to specify which opc-ua type is used for the Identifier. In addition to the :class:`~asyncua.ua.uatypes.NodeId`
 class, there is also the a :class:`~asyncua.ua.uatypes.ExpandedNodeId` which adds the 
 :attr:`~asyncua.ua.uatypes.ExpandedNodeId.NamespaceUri` and :attr:`~asyncua.ua.uatypes.ExpandedNodeId.ServerIndex`
-attributes to make the ID unique accross different servers and namespaces.
+attributes to make the ID unique across different servers and namespaces.
 
 
 Creating NodeId's
 -----------------
 
-As allready mentioned above, the NodeId class supports different types for the Identifier.
-The type is handled automatically on class instanciation and there is usually no need
+As already mentioned above, the NodeId class supports different types for the Identifier.
+The type is handled automatically on class instantiation and there is usually no need
 to set the type manually. Creating new NodeIds usually looks like this:
 
 .. code-block:: python
@@ -158,8 +158,8 @@ to access a child several levels deeper than the current node:
     >>> await c.nodes.objects.get_child(['2:MyObject', '2:MyVariable'])
     Node(NodeId(Identifier=2, NamespaceIndex=2, NodeIdType=<NodeIdType.FourByte: 1>))
 
-Here we start at the objects node an traverse via MyObject to MyVariable. Allways keep in
+Here we start at the objects node an traverse via MyObject to MyVariable. Always keep in
 mind that browsing through the nodes will create network traffic and server load. If
-you allready know the NodeId using :meth:`~asyncua.client.client.Client.get_node` should
-be prefered. You might also consider caching NodeIds which you found through browsing
+you already know the NodeId using :meth:`~asyncua.client.client.Client.get_node` should
+be preferred. You might also consider caching NodeIds which you found through browsing
 to reduce the traffic. 

docs/usage/common/overview.rst

@@ -16,7 +16,7 @@ asyncua.common package
 
 The :mod:`asyncua.common` package is provides the core functionality of the library.
 Several important parts life in this subpackage, for example the :class:`~asyncua.common.node.Node`
-class and the :mod:`~asyncua.common.subscription` module. You can find usage exampels
+class and the :mod:`~asyncua.common.subscription` module. You can find usage examples
 of these classes and functionalities in the following sections.
 
 

docs/usage/get-started/minimal-client.rst

@@ -38,7 +38,7 @@ of the variable. The :meth:`~asyncua.common.node.Node.get_child` method of the r
 
 .. note:: Using :meth:`~asyncua.common.node.Node.get_child` will perform a server request
     in the background to resolve the path to a node. Extensive usage of this method can
-    create a lot of network traffic which is not strictly required if the node id is knwon.
+    create a lot of network traffic which is not strictly required if the node id is known.
     If you know the node id it's better to use the :meth:`~asyncua.client.client.Client.get_node`
     method of the client. For example :code:`client.get_node("ns=2;i=2")` or
     :code:`client.get_node(ua.NodeId(2, 2))` could be used in the example. 
@@ -57,4 +57,4 @@ Calling Methods
 The method interface is similar to the interface of variables. In the example the special
 node :code:`client.nodes.objects`, which is in fact just a shortcut to the :code:`0:Objects`
 node, is used to call the `2:ServerMethod` on it. The :meth:`~asyncua.common.node.Node.call_method`
-must be called on the parent node of the actuall method node.
+must be called on the parent node of the actual method node.

docs/usage/get-started/minimal-server.rst

@@ -7,7 +7,7 @@ Most of the hard work will be hidden behind the scene and we only need to implem
 application specific code.
 
 The complete code will look like the code below. In the next sections we will look at
-the different parts of the code, so don't be overhelmed by the code snippet!
+the different parts of the code, so don't be overwhelmed by the code snippet!
 
 .. literalinclude:: ../../../examples/server-minimal.py
     :caption: server-minimal.py
@@ -105,7 +105,7 @@ by clients:
 To do this, a function, decorated with the :meth:`~asyncua.common.methods.uamethod` decorator,
 is created and, similar to the objects and variables, registered on the server. It would
 also be possible to register a undecorated function on the server, but in this case the
-coversion from and to UA Variant types would be up to us.
+conversion from and to UA Variant types would be up to us.
 
 Starting the Server
 ===================

docs/usage/get-started/opc-ua-basics.rst

@@ -23,7 +23,7 @@ External References
 https://reference.opcfoundation.org
     Luckily the complete documentation about OPC-UA is available for free. As this is
     the official reference documentation, you will find links to this page in the
-    source code of this package and also in this documentation where necesary.
+    source code of this package and also in this documentation where necessary.
 
 https://www.open62541.org
     Open Source (MPL v2.0) OPC UA stack implemented in C. If you need a library which

docs/usage/sync/overview.rst

@@ -3,7 +3,7 @@ Synchronous Interface
 =====================
 
 You don't like to work with ``asyncio`` and ``async`` / ``await`` or you need to integrate
-the package in code wich is not using ``asyncio``? The :mod:`asyncua.sync` module provides
-a convinient wrapper around the client and server and provides synchronous versions of
+the package in code which is not using ``asyncio``? The :mod:`asyncua.sync` module provides
+a convenient wrapper around the client and server and provides synchronous versions of
 the node and subscription classes. This allows direct usage of the package, using the same
 interface as for ``async`` code, without writing custom wrappers.