Structural typing (duck typing) with ASDF Schemas

[ketozhang]

Structural typing or better known as duck typing allows you, as the consumer, to:

1. Pick the parts of your producer's data model that you wish to integrate into your system.
2. When you don't have or don't want to use your producer's ASDF extension:
   • You do not like how they deserialize and want to use your own.
   • You do not want to depend on your producer's Python package.

My motivation for this is, when I read an ASDF file, I am already using duck typing because I do not want my producer's data model to be exposed into my application (e.g., anticorruption layer).

I want to brainstorm what something like this might look like. I can think of two styles:

1. Consumer writes their own ASDF schema using a subset of Producer's schema. Type widening is implemented by using the same ASDF tag as the Producer but with loose constraints (e.g., removing value constraints lt gt).
2. Consumer writes their own schema replacing all of Producer's tags with a new tag (with better semantics for duck typing).

Idea (1) you can already do with no changes. Idea (2) I am not entirely convinced a new tag is necessary since you can do this with JSON object:

%YAML 1.1
---
$schema: "http://stsci.edu/schemas/yaml-schema/draft-01"
id: "uri://consumer/schemas/images-protocol-1"

title: Image
description: >-
  An image with pixel data and associated WCS.

allOf:
  - type: object
    properties:
      data:
        title: "Image data"
        description: The pixel array.
        tag: "tag:stsci.edu:asdf/core/ndarray-1.1.0"
      wcs:
        title: "WCS"
        description: World coordinate system.
        type: object
        properties:
          aperture_name:
            title: "Aperture name"
            description: Name of the instrument aperture. We only care about WFI01 <insert reason>
            type: string
            enum:
              - WFI01_FULL
        required: [aperture_name]
    required: [data, wcs]
...

..., however I argue the JSON object schema semantic is not very readable at scale. I think we can come up with a better tag with a simpler semantic vocabulary.

---

I'm posting this here in asdf instead of asdf-standard because I think it could go both ways and not all languages favor duck typing. Feel free to move this thread.

[ketozhang]

I would argue you're better off doing this with Pydantic unless you have a reason why you want to propagate the consumer-side schemas (e.g., not everyone in the consumer side uses Pydantic or Python).

# // dependencies = ['asdf', 'consumer']
import asdf
from consumer.domain.models import Image
from consumer.dto.models import ImageDTO

# Validate & parse to your domain object
with asdf.open('/path/to/producer/file.asdf') as af:
    img = Image.model_validate(af.tree)

# Validate & parse to your data transfer object
with asdf.open('/path/to/producer/file.asdf') as af:
    img = ImageDTO.model_validate(af.tree)