From ca19389c60dbbf99905605e90769ebe6ee665a6c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E6=B5=A6=E5=8E=9F=E5=96=9C=E5=8A=A9?= Date: Mon, 28 May 2018 17:31:20 -0300 Subject: [PATCH] Fixing typos on docs (#694) --- docs/attachments.rst | 2 +- docs/client.rst | 16 ++++++++-------- docs/headers.rst | 2 +- docs/helpers.rst | 2 +- docs/in_depth.rst | 2 +- docs/plugins.rst | 2 +- docs/transport.rst | 7 +++---- docs/wsa.rst | 6 +++--- 8 files changed, 19 insertions(+), 20 deletions(-) diff --git a/docs/attachments.rst b/docs/attachments.rst index 282121e31..2064c9c45 100644 --- a/docs/attachments.rst +++ b/docs/attachments.rst @@ -3,7 +3,7 @@ SOAP Attachments (multipart) ============================ If the server responds with a Content-type: multipart, a MessagePack object -will be returned. It contains a root object and a number of attachments. +will be returned. It contains a root object and some attachments. Example based on https://www.w3.org/TR/SOAP-attachments diff --git a/docs/client.rst b/docs/client.rst index c89341c8a..c18bcf0d5 100644 --- a/docs/client.rst +++ b/docs/client.rst @@ -7,7 +7,7 @@ The Client object The :class:`Client` is the main interface for interacting with a SOAP server. It provides a ``service`` attribute which references the default binding of the client (via a :class:`ServiceProxy` object). The default binding can be specified -when initating the client by passing the ``service_name`` and ``port_name``. +when initiating the client by passing the ``service_name`` and ``port_name``. Otherwise the first service and first port within that service are used as the default. @@ -16,9 +16,9 @@ default. Caching of WSDL and XSD files ------------------------------ -When the client is initialised it will automaticaly retrieve the wsdl file -passed as argument. This wsdl file generally references various other wsdl and -xsd files. By default Zeep doesn't cache these files but it is however +When the client is initialized it will automatically retrieve the WSDL file +passed as argument. This WSDL file generally references various other WSDL and +XSD files. By default Zeep doesn't cache these files but it is however advised to enable this for performance reasons. Please see :ref:`transport_caching` how to enable this. To make it easy to @@ -49,7 +49,7 @@ kwarg ``strict=False`` to the ``Client``. Disabling strict mode will change the following behaviour: - The XML is parsed with the recover mode enabled - - Non optional elements are allowed to be missing in xsd:sequences + - Nonoptional elements are allowed to be missing in xsd:sequences Note that disabling strict mode should be considered a last resort since it might result in data-loss between the XML and the returned response. @@ -100,15 +100,15 @@ operation on the binding. client.service.X() # The operation can also be called via an __getitem__ call. - # This is usefull if the operation name is not a valid + # This is useful if the operation name is not a valid # python attribute name. client.service['X-Y']() Using non-default bindings -------------------------- -As mentioned by default Zeep picks the first binding in the wsdl as the -default. This binding is availble via ``client.service``. To use a specific +As mentioned by default Zeep picks the first binding in the WSDL as the +default. This binding is available via ``client.service``. To use a specific binding you can use the ``bind()`` method on the client object: diff --git a/docs/headers.rst b/docs/headers.rst index 65ef7d832..af13e190c 100644 --- a/docs/headers.rst +++ b/docs/headers.rst @@ -6,7 +6,7 @@ elements can be passed to all operations using the ``_soapheaders`` kwarg. There are multiple ways to pass a value to the soapheader. -1. When the soap header expects a complex type you can either pass a dict or +1. When the SOAP header expects a complex type you can either pass a dict or an object created via the ``client.get_element()`` method. 2. When the header expects a simple type value you can pass it directly to the ``_soapheaders`` kwarg. (e.g.: ``client.service.Method(_soapheaders=1234)``) diff --git a/docs/helpers.rst b/docs/helpers.rst index daac87ae0..952d75e84 100644 --- a/docs/helpers.rst +++ b/docs/helpers.rst @@ -1,7 +1,7 @@ Helpers ======= -In the `zeep.helpers` module the following helpers functions are available: +In the `zeep.helpers` module the following helper functions are available: .. automodule:: zeep.helpers :members: diff --git a/docs/in_depth.rst b/docs/in_depth.rst index 91f86ce12..51d2d4807 100644 --- a/docs/in_depth.rst +++ b/docs/in_depth.rst @@ -11,7 +11,7 @@ of the time this is an implementation detail, Zeep should offer the same API to the user independent of the underlying protocol. One of the first things you will do if you start developing an interface to a -wsdl webservice is to get an overview of all available operations and their +wsdl web service is to get an overview of all available operations and their call signatures. Zeep offers a command line interface to make this easy. diff --git a/docs/plugins.rst b/docs/plugins.rst index e79a3f923..5dbf434a0 100644 --- a/docs/plugins.rst +++ b/docs/plugins.rst @@ -5,7 +5,7 @@ Plugins .. versionadded:: 0.15 You can write plugins for zeep which can be used to process/modify data before -it is send to the server (egress) and after it is received (ingress). +it is sent to the server (egress) and after it is received (ingress). Writing a plugin is really simple and best explained via an example. diff --git a/docs/transport.rst b/docs/transport.rst index 328913b94..020809ed9 100644 --- a/docs/transport.rst +++ b/docs/transport.rst @@ -5,7 +5,7 @@ need to create an instance of the Transport class yourself. SSL verification ---------------- -If you need to verficate the SSL connection (in case you have a self signed certificate for your host), the best way is to create a :class:`requests.Session` instance and add the information to that Session, so it keeps persistent: +If you need to verify the SSL connection (in case you have a self-signed certificate for your host), the best way is to create a :class:`requests.Session` instance and add the information to that Session, so it keeps persistent: .. code-block:: python @@ -21,9 +21,8 @@ If you need to verficate the SSL connection (in case you have a self signed cert transport=transport) .. HINT:: - - Make sure that the certificate you refer to is a CA_BUNDLE, meaning it contains a root CA and an intermediate CA. - Accepted are only X.509 ASCII files (file extension ``.pem``, sometimes ``crt``). If you have two different files, you must combine them manually into one. +Make sure that the certificate you refer to is a CA_BUNDLE, meaning it contains a root CA and an intermediate CA. +Accepted are only X.509 ASCII files (file extension ``.pem``, sometimes ``.crt``). If you have two different files, you must combine them manually into one. Alternatively, instead of using ``session.verify`` you can use ``session.cert`` if you just want to use an SSL client certificate. diff --git a/docs/wsa.rst b/docs/wsa.rst index 64fdc4895..5ddbb4c1e 100644 --- a/docs/wsa.rst +++ b/docs/wsa.rst @@ -5,10 +5,10 @@ WS-Addressing (WSA) .. versionadded:: 0.15 Zeep offers (experimental) support for the `ws-addressing specification`_. The -specification defines a number of soap:Header elements which basically allows +specification defines some soap:Header elements which basically allows advanced routing of the SOAP messages. -If the WSDL documnt defines that WSA is required then Zeep will automatically +If the WSDL document defines that WSA is required then Zeep will automatically add the required headers to the SOAP envelope. In case you want to customize this then you can add the :class:`~zeep.wsa.WsAddressPlugin` to the :attr:`Client.plugins` list. @@ -29,7 +29,7 @@ For example: .. note:: The support for ws-addressing is experimental. If you encounter any issues - then please don't hesistate to create an issue on the github repository. + then please don't hesitate to create an issue on the github repository. .. _ws-addressing specification: https://www.w3.org/TR/2006/REC-ws-addr-soap-20060509/