As of now we try to make the source of an xref (the Resource with the xref) and the target of the xref (the Resource that is pointed to by an xref) look as similar as possible - to the point where the main way to tell the different is the presence of the xref attribute in the source. This is nice from an usability perspective since the client should (in most cases) not really care if the Resource is "local" or not. However, there may be times when knowing if a Resource is part of an xref usage is critical. For example, let's say there is a Resource that has 10 other Resources pointing to it (via 10 xref usages). Deleting any one of those ten is safe w.r.t.. the other 10 Resources (9 xrefs + the target of the xref). However, deleting the target of the xref will break the 10 xref usage Resources. There's no mechanism in place to help detect this situation so that a client/user would question whether or not it's safe to delete a Resource w.r.t. xrefs.
Some options I can think of:
1 - do nothing and expect the user to keep track of it - if they want to at all
2 - provide some kind of "xref target count" field on the target of an xref so people can easily see how many other Resources are pointing to it. I wonder if this "count" is reliable/safe once auth is added into the system because should it probably include pointers from Resources that the user doesn't have access to. However, if the client can't find/see the other Resources then that'll be annoying. Not sure of the impl consequences of this one since it's likely a calculated field and people may want to query over it (e.g. find all Resources with an "xrefcount" value > 0 ) - so if it's not stored in the DB, but instead calculated during serialization, then people might not be able to query it.
3 - provide an API for people to query whether a Resource is the target of an xref. Similar to 2 but not part of the Resource metadata. Only real benefit I can see of this one is that from an implementation perspective it might be easier to not have to calculate this value each time a Resource is serialized.
4 - do nothing but add text to our Primer suggesting that people put shared resources into a Group that's specifically meant to be for "shared" Resources and not really part of normal queries. Then all other (normal) Resources will use xref and can be safely deleted w/o fear of deleting the target of an xref. Not much different than 1 but at least it provides some guidance.
I'm leaning towards 2 but I think we need to think more about the impl and auth ramifications.
As of now we try to make the source of an xref (the Resource with the
xref) and the target of the xref (the Resource that is pointed to by anxref) look as similar as possible - to the point where the main way to tell the different is the presence of thexrefattribute in the source. This is nice from an usability perspective since the client should (in most cases) not really care if the Resource is "local" or not. However, there may be times when knowing if a Resource is part of an xref usage is critical. For example, let's say there is a Resource that has 10 other Resources pointing to it (via 10xrefusages). Deleting any one of those ten is safe w.r.t.. the other 10 Resources (9 xrefs + the target of the xref). However, deleting the target of the xref will break the 10xrefusage Resources. There's no mechanism in place to help detect this situation so that a client/user would question whether or not it's safe to delete a Resource w.r.t. xrefs.Some options I can think of: 1 - do nothing and expect the user to keep track of it - if they want to at all 2 - provide some kind of "xref target count" field on the target of an xref so people can easily see how many other Resources are pointing to it. I wonder if this "count" is reliable/safe once auth is added into the system because should it probably include pointers from Resources that the user doesn't have access to. However, if the client can't find/see the other Resources then that'll be annoying. Not sure of the impl consequences of this one since it's likely a calculated field and people may want to query over it (e.g. find all Resources with an "xrefcount" value > 0 ) - so if it's not stored in the DB, but instead calculated during serialization, then people might not be able to query it. 3 - provide an API for people to query whether a Resource is the target of an xref. Similar to 2 but not part of the Resource metadata. Only real benefit I can see of this one is that from an implementation perspective it might be easier to not have to calculate this value each time a Resource is serialized. 4 - do nothing but add text to our Primer suggesting that people put shared resources into a Group that's specifically meant to be for "shared" Resources and not really part of normal queries. Then all other (normal) Resources will use xref and can be safely deleted w/o fear of deleting the target of an xref. Not much different than 1 but at least it provides some guidance.
I'm leaning towards 2 but I think we need to think more about the impl and auth ramifications.