From 7f9903d5b231d8ebcbbbeb6cf95cb852bb574140 Mon Sep 17 00:00:00 2001
From: Raphael Krupinski <10319569-mattesilver@users.noreply.gitlab.com>
Date: Tue, 9 Jan 2024 22:15:28 +0100
Subject: [PATCH] =?UTF-8?q?=F0=9F=93=9D=20Update=20documentation.?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 docs/python_representation.md | 25 ++++++++++++++-----------
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/docs/python_representation.md b/docs/python_representation.md
index 1768bc9..19b79b3 100644
--- a/docs/python_representation.md
+++ b/docs/python_representation.md
@@ -1,6 +1,7 @@
 # Python code representation of OpenAPI document
 
-The goal of python representation is to allow python code to fully replace OpanAPI document, allow Lapidary library to prepare a HTTP request and parse the response, in a way compatible with the server describe by that OpenAPI document.
+The goal of python representation is to allow python code to fully replace OpanAPI document, allow Lapidary library to prepare a HTTP request and parse the response, in a way compatible with the
+server describe by that OpenAPI document.
 
 The python representation must be fully sufficient, must not require the original document to function, and usage must execute a valid exchange with a server.
 
@@ -32,24 +33,26 @@ The possible work-arounds are:
 Lapidary uses annotations, which declares parameter location and may be used to provide the name.
 
 ```python
-from typing import Annotated
-from lapidary.runtime.model.params import CookieParam
-
-
-async def operation(
-        self,
-        param1_c: Annotated[str, CookieParam('param1')],
-):
-    ...
+from typing import Annotated, Self
+from lapidary.runtime import Cookie, ClientBase
+
+class Client(ClientBase):
+    async def operation(
+        self: Self,
+        *,
+        param1_c: Annotated[str, Cookie('param1')],
+    ):
+        pass
 ```
 
 #### Serialization
 
-Serialization in OpenAPI is a rather complex subject, and not well defined. 
+Serialization in OpenAPI is a rather complex subject, and not always defined well.
 
 An example of undefined behaviour is serialization of nested object with simple or form style, which is neither defined nor forbidden.
 
 Possible solution are:
+
 - explicitly forbidding certain cases
 - extending the specification, and optionally accepting extra parameters (i.e. field delimiter in nested objects)
 - accepting custom de/serialization function