You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Custom Node subclasses cannot be deserialized: no extension story beyond the generated Types enumeration #167
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.
Activity