Fannon
commented
3 weeks ago With adding more levels, you can only solve the relationship problem if you can model it as compositions, which is not very flexible. Another approach could be to actually flatten the xRegistry and allow associations (via xref) between the resources.
Another problem that will come up with graph traversal is that you want to navigate / query / filter relationships in both directions. In the model you'll usually define the relationship from the direction who owns / has the knowledge of the relation. E.g. a message would probably point to a schema, not vice versa (because the same schema could also be used by other messages, unknowingly to the schema). But still you may want to find out in which messages a particular schema is used.
We need an easy way for a client to answer the question: Which Endpoints are impacted by a Schema change?
Right now this is a non-trivial task requiring many steps and queries.
I believe the current paths to consider are:
And it gets more interesting when we think about how we need to take into account when a Schema's default version points to the SchemaVersion of interest.
I believe stepping into nested children is already covered by today's filters via our dot(.) notion. This means it's the "->" steps are are "plain old URLs" that's the main problem we need to address:
A few options come to mind:
1 - support the idea of more than 2 levels (groups, resources), so that people can use nesting rather than URL/pointers across these boundaries. One big issue with this is that it makes it really hard to share common entities (such as Schemas) across higher-level entities because normally you can't have 2 parents when things are embedded. However, it might be possible via the "xref" feature we added. That would, however, require its real parent to never go away. It might require "xref" to be expanded to support pointing to Groups and not just Resources.
2 - an issue with 1) is that (if it works) it may only work for well-defining groupings. Meaning, pre-defined child collections. It's not clear to me if it'll work in extension attributes that are collections, or even just simple URL-type of attributes that want to point to some other entity. To solve these we may need to leverage the "associations" concept that @deissnerk has mentioned. If we define a special URL type that is more than just a string (e.g. it's an xref-like pointer) then it might be possible to implement a system where a filer expression can traverse these references in the same way they walk into nested entities. One nice thing about this is that (I think) it would allow people to define multi-level registries (not just 2 level ones) because then they can have groups of groups, and not just groups of resources (which is what Endpoints are today: Endpoint->Group-of-MessageGroups->MessageGroup->Message).