Custom Node subclasses cannot be deserialized: no extension story beyond the generated Types enumeration

[ehennestad]

A class that is not in the generated openminds.enum.Types enumeration cannot be deserialized. Deserializer.instantiateAll resolves every node through Types.fromAtType, which raises OPENMINDS_MATLAB:Types:UnknownAtType for anything the pipeline did not emit. A user-defined openminds.Node subclass can be constructed and serialized, but a document containing it will not load, and Collection cannot hold a type it cannot read back. The same closed lookup sits behind openminds.fromTypeName and the resolver registry.

So there is no story for extension schemas: a lab that needs a type openMINDS does not have, or a project that prototypes a schema before proposing it upstream, cannot use this toolbox for it end to end.

openMINDS_Python is only slightly better: its registry is a runtime dictionary, and since 0.4.0 an external class is accepted if it declares preferred_import_path (added so fairgraph could share the registry). Neither library documents extension as a supported use.

Proposal:

• A runtime registry beside the generated enumeration, where a class can register its type IRI, so fromAtType, fromTypeName and the deserializer consult both.
• A documented minimal contract for a custom type: subclass openminds.Node, declare X_TYPE, LINKED_PROPERTIES, EMBEDDED_PROPERTIES and Required, register the class. The test fixture ommtest.helper.UntypedLinkNodeFixture on the name-map fix branch is already such a class and shows how little is needed.
• Decide whether custom types are allowed in the @context the serializer writes, since their IRIs will not be under the openMINDS vocabulary.

🤖 Generated with Claude Code