File: use_cases.rst

package info (click to toggle)
python-asdf 2.14.3-1%2Bdeb12u1
  • links: PTS, VCS
  • area: main
  • in suites: bookworm
  • size: 2,280 kB
  • sloc: python: 16,612; makefile: 124
file content (172 lines) | stat: -rw-r--r-- 8,258 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
.. _extending_use_cases:

================
Common use cases
================

This section is intended as a kind of index to the rest of the
"Extending ASDF" documentation.  Here we list common use cases
and link to the relevant documentation sections that are needed
to get the job done.

Validate an ASDF tree against a schema
======================================

The `asdf` library already validates individual tagged objects within the tree,
but what if we want to validate the structure of the tree itself?  Such
"document schemas" can be associated with an `~asdf.AsdfFile` using the
``custom_schema`` argument, but this argument accepts a URI and the asdf
library needs to know how to access the schema content associated with that
URI.

1. Designate a URI for the schema.  See :ref:`extending_uris_entities_schemas` for
   recommendations on schema URI structure.
2. Write the schema.  See :ref:`extending_schemas` if you're new to authoring schemas.
3. Install the schema as an `asdf` library resource.  See :ref:`extending_resources`
   for an overview of resources in `asdf` and options for installing them.

Serialize a new type
====================

This section summarizes the steps needed to serialize a new type to an ASDF file.
We'll describe three options, starting with the most expedient and growing
progressively more formal.

Quick and dirty, for personal use
---------------------------------

In this scenario, we want to serialize a new Python type to an ASDF file, but
we're not planning on widely sharing the file, so we want to cut as many corners
as possible.  Here are the minimal steps needed to get instances of that type
into the file and back again:

1. Identify the Python type to serialize.  We'll need to know the fully-qualified
   name of the type (module path + class name).

2. Select a tag URI that will signify the type in YAML.  See :ref:`extending_uris_entities_tags`
   for recommendations on tag URI structure.

3. Implement a `~asdf.extension.Converter` class that converts the type to
   YAML-serializable objects and back again.  See :ref:`extending_converters`
   for a discussion of the Converter interface.

4. Implement an `~asdf.extension.Extension` class which is the vehicle
   for plugging our converter into the asdf library.  See :ref:`extending_extensions`
   for a discussion of the Extension interface.

5. Install the extension.  There are multiple ways to do this, but the path
   of least resistance is to install the extension at runtime using `~asdf.config.AsdfConfig`.
   See :ref:`extending_extensions_installing_asdf_config`.

Now instances of our type can be added to an `~asdf.AsdfFile`'s tree and
serialized to an ASDF file.

For sharing with other Python users
-----------------------------------

Now say our files are getting out into the world and into the hands of
other Python users.  We'll want to build an installable package
around our code and use the `asdf` library's entry points to make our
extension more convenient to use.  We should also think about adding
a schema that validates our tagged objects, so if someone manually edits
a file and makes a mistake, we get a clear error when `asdf` opens the file.

1. Identify the Python type to serialize.  We'll need to know the fully-qualified
   name of the type (module path + class name).

2. Select a tag URI that will signify the type in YAML.  See :ref:`extending_uris_entities_tags`
   for recommendations on tag URI structure.

3. Designate a URI for the schema.  See :ref:`extending_uris_entities_schemas` for
   recommendations on schema URI structure.

4. Write the schema that will validate the tagged object.  See :ref:`extending_schemas`
   if you're new to authoring schemas.

5. Make the schema installable as an `asdf` library resource.  See :ref:`extending_resources`
   for an overview of resources in `asdf` and :ref:`extending_resources_entry_points` for
   information on installing resources via an entry point.

6. Implement a `~asdf.extension.Converter` class that converts the type to
   YAML-serializable objects and back again.  See :ref:`extending_converters`
   for a discussion of the Converter interface.  Refer to the schema to ensure
   that the Converter is writing YAML objects correctly.

7. Implement an `~asdf.extension.Extension` class which is the vehicle
   for plugging our converter into the `asdf` library.  See :ref:`extending_extensions`
   for a discussion of the Extension interface.  We'll need to associate the schema
   URI with the tag URI in our tag's `~asdf.extension.TagDefinition` object.

8. Install the extension via an entry point.  See :ref:`extending_extensions_installing_entry_points`.

Now anyone who installs the package containing the entry points will be able
to read, write, and validate ASDF files containing our new tag!

For sharing with users of other languages
-----------------------------------------

Finally, let's consider the case where we want to serialize instances of our type
to an ASDF file that will be read using ASDF libraries written in other languages.
The problem with our previous efforts is that the extension definition exists
only as Python code, so here we'll want to create an additional YAML document
called an extension manifest that defines the extension in a language-independent way.

1. Identify the Python type to serialize.  We'll need to know the fully-qualified
   name of the type (module path + class name).

2. Select a tag URI that will signify the type in YAML.  See :ref:`extending_uris_entities_tags`
   for recommendations on tag URI structure.

3. Designate a URI for the schema.  See :ref:`extending_uris_entities_schemas` for
   recommendations on schema URI structure.

4. Write the schema that will validate the tagged object.  See :ref:`extending_schemas`
   if you're new to authoring schemas.

5. Write an extension manifest document that describes the tag and schema that
   we're including in our extension.  See :ref:`extending_manifests` for information
   on the manifest format.

5. Make the schema and manifest installable as `asdf` library resources.  See
   :ref:`extending_resources` for an overview of resources in `asdf` and
   :ref:`extending_resources_entry_points` for information on installing resources
   via an entry point.

6. Implement a `~asdf.extension.Converter` class that converts the type to
   YAML-serializable objects and back again.  See :ref:`extending_converters`
   for a discussion of the Converter interface.  Refer to the schema to ensure
   that the Converter is writing YAML objects correctly.

7. Use `asdf.extension.ManifestExtension.from_uri` to populate an extension with the Converter
   and information from the manifest document.  See :ref:`extending_extensions_manifest` for
   instructions on using ManifestExtension.

8. Install the extension via an entry point.  See :ref:`extending_extensions_installing_entry_points`.

That's it!  Python users should experience the same convenience, but now the manifest
document is available as a reference for developers who wish to implement support
for reading our tagged objects in their language of choice.

Support a new block compressor
==============================

In order to support a new compression algorithm for ASDF binary blocks,
we need to implement the `~asdf.extension.Compressor` interface and install
that in an extension.

1. Select a 4-byte compression code that will signify the compression algorithm.

1. Implement a `~asdf.extension.Compressor` class that associates the 4-byte code with
   compression and decompression methods.  See :ref:`extending_compressors` for a discussion
   of the Compressor interface.

2. Implement an `~asdf.extension.Extension` class which is the vehicle
   for plugging our compressor into the `asdf` library.  See :ref:`extending_extensions`
   for a discussion of the Extension interface.

3. Install the extension via one of the two available methods.  See
   :ref:`extending_extensions_installing` for instructions.

Now the compression algorithm will be available for both reading and writing ASDF files.
Users writing files will simply need to specify the new 4-byte compression code when making calls
to `asdf.AsdfFile.set_array_compression`.