"relation" type vs "url" type
Opened this issue · 5 comments
If someone wants to add a new attribute to their model that points to a schema doc they now have to choose between "relation" and "url" types, depending on whether the schema lives in the same registry or not. This might be problematic for a few reasons:
1 - it means people can't point to both internal and external schema docs from the same attribute. Yes they can choose "url" and but then they lose the benefit of type checking (or other future features that might come up due to "relation" being available)
2 - the choice of "one" vs "multiple" (distributed) registries will now influence which type of attribute to use. This is unfortunate because it means:
a) the same model can't be used for both cases
b) no ability to export/import between the two worlds
One option is to remove "relation" but keep the "target" (optional) attribute and it only applies when the value of the url is a relative URL. We may need to also require that relative URLs be XIDs (when "target" is specified in the model?). Type checking would be disabled when the URL isn't relative.
Not sure about this proposal, but it feels like something needs to change otherwise "relation" might only be valuable in cases where everything lives in the same registry. And I'm not sure how popular that would be outside of demo scenarios.
I'm not sure I understand the concern. If I recall our discussion in December correctly, we decided not to work on federation scenarios for now. As a result, the idea was to stick to relative URIs for xids for the time being. This way don't need a proper URI scheme, yet.
My original proposal included absolute URIs as well. One of my proposals was to introduce clientreadonly URL attributes, the server could generate based on the resolution of an xid.
So, in my opinion, the decision should be between a (typed) relation to another xRegistry entity and a freestyle URL to any document.
My concern isn't "federated" per se... it's more about how someone may not have all 3 (endpoints, message, and schema) registries deployed at the same location. In which case the pointers to things like 'schemas' can't be "relations" they must be URLs. Which by itself is fine, but if someone DOES decide to deploy all 3 in the same location then if they want to take advantage of "type checking" for these pointers they would need to manually go into the model and change these URLs to "relations" and add the appropriate "target". Do-able, but isn't that kind of annoying that the user would need to define at least 2 different models based on how things are deployed?
1/8 - go with "One option is to remove "relation" but keep the "target" (optional) attribute and it only applies when the value of the url is a relative URL. " option - but we need to talk with @deissnerk first
How would that be useful to a client? Only if there is a target specified, the attribute indirectly identifies the related entity. Without a target, the client needs to be prepared for surprises. The original idea of adding a relation type to introduce well-defined relations between xRegistry entities would be abandoned.
@deissnerk the idea is this:
- remove "relation" type and tell people to just use "url"
- add an optional "target" property to the attribute (as we have with the latest PR), so that people can tell us what type the URL points to (when it's a relative url)
- if, at runtime, the value of the attribute is an absolute URL then target isn't used and it's just a URL that the server treats as a string
- but, if it's a relative URL and target is set then we do what "relation" does today... we can type check to make sure that the relative URL points to the correct type of entity
this allows an attribute to point to any random URL (w/o type checking) or a local entity with type checking (if they provide us the "target"). Best of both worlds.
Make sense?