In further consideration, what seems missing from JSON encoding is an ANY type and a CHOICE type. With these and proper type encoding extension to JSON, we could pass arbitrary types w/o being required to specify a specific decoding structure. I think this is so. Types would be helpful. I found TJSON, which may be good, but no arbitrary types, still.

I notice JSON decoding is where magic happens and it requires full specification of what is expected. Perhaps there is a way for ANY & CHOICE with a CustomMapper. Contrarily, Fuel does all analysis on encoding, the front side, and encodes the found clusters on-stream so the materialized is lightweight. ASN1MODULES does a little of both with external types but also with ANY & CHOICE.

In looking at Fuel-Core, here are main classes..,

I find I do not necessarily have a specific question regarding a specific implementations, but a higher-level question of feasible solution. I need substitutable, type-relevant JSON encoding, perhaps based upon JSON Schemas.

I am looking at ASN1Modules & types, Fuel clusterings/substitutions and NeoJSON clusters & mappers. Is it feasible to bring all these together? I would use ASN1Types, Fuel graph walking/substitutions and NeoJSON encoding and cluster hooks.

Fuel also has Clusters but I see that Fuel encodes these clusters in each encoding. I am torn about this philosophically: good to have self-describing data encoding, but not suitable for JSON, unless just a type-name extension. Lightweight & robust descriptions? Well, this is all Fuel cluster specs within the encoding really is: a type-specification.

The aspect of NeoJSON that has me wondering is the lack of polymorphism in type-spec lookup and recursive substitution. This is where Fuel shines, I feel.

So what is the vision of the end state encoder? Use ASN1 Types as cluster descriptors, Fuel proxification on materializations and NeoJSON encoding and mappers.

Would you have for me guidances in this area?

- HH