Known issues

[sdboyer]

Thema has a number of outstanding issues to address. Some are more critical than others, and not all need be addressed before we can call Thema stable. Each one of merits its own discussion, but i'm going to use this a scrappy list centralized in a single, easily-linked-to issue as a TODO list until time allows to get each one written up properly.

• Adding generic composition, which we've already halfway genericized in Grafana
• A clear, consistent answer for how object headers (at least the thema version, but possibly more) are attached to schema, and the degrees of freedom for individual lineage authors to choose their object headers
• Settle on openness/closedness for various components in the system
• permissibility of creating outside-the-lineage references
• URIs/a registry/something; is this independent of CUE packaging rules
• Invariant for the concreteness of a lens relation
• Is it a mistake to treat lenses as mutable-after-publishing? The tradeoff seems to be right - it's too brittle to assume the translation mechanism is bug-free, because that would mean people could paint themselves into dead-ends. But it also complicates the publishing model
• nonlinear translation/lens pathing, to avoid more dead-end painting. A good impl here could change the calculus on lens immutability
• Naming for "sequence number, schema number"
• really, really need to have a name/uri field for these. But how do we square that with CUE package management?
• a mechanism for simplifying copying most fields in lens mappings
• special mechanism for schematizing fields that are expected to contain (string?) references to other thema lineage
• Lens shape, does it need refactoring to support nuanced default translation
• need a mode for loading in Go that can ignore certain constraint violations...maybe? this is the list.MinItems(1) is invalid problem. Also, how can we the non-zero list length available for pseudofuncs that work on a lineage
• Express all invariants in pure CUE