You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the interest of resolving #177 , which is a prioritized issue, I read through many of the open issues labelled auxiliary resources. I may still have missed something. As @csarven notes, we need different relation types for different auxiliary resource types, otherwise, a client would not know what to get. In #172 , @justinwb suggested a few types. However, I have been looking for commonalities, and I think we'd resolve many issues if we took a more general approach. I think that "server managed" is one of several dimensions that auxiliary resources can map to, rather than a type in its own right. If we identify the dimensions that can be used to build auxiliary resource types, then we can in using hypermedia ( #270 ), define types in terms of those dimensions.
The four dimensions that I have identify so far are whether an auxiliary resource
is tied to the lifecycle of its resource (LC).
has its own access control, or uses its parent's access control (AC).
is server managed (SM)
can timeshift (e.g. Memento) (TS)
As we define the Link relation, the type URI itself should resolve to a definition based on these dimensions as well as other data.
The text was updated successfully, but these errors were encountered:
I can make a stab at defining some of the mentioned aux resource types in these terms, to make it more concrete. I use the terms in paranthesis in the list above, and use + or - to indicate whether it uses the dimension or not.
Perhaps we should also be clearer about what should be an auxiliary resource and what should not. It seems to me that a few of these, like provenance, would at least sometimes be a normal contained, resource.
The resolution of the dimensions can vary. What I wrote in #270 (comment) is fairly flat and I think gives more precision on the characteristics of auxiliary resources. And, then there is additional consideration/definition about auxiliary resources which may not necessarily be a dimension - whether auxiliary resources can every be part of containment.
In the interest of resolving #177 , which is a prioritized issue, I read through many of the open issues labelled auxiliary resources. I may still have missed something. As @csarven notes, we need different relation types for different auxiliary resource types, otherwise, a client would not know what to get. In #172 , @justinwb suggested a few types. However, I have been looking for commonalities, and I think we'd resolve many issues if we took a more general approach. I think that "server managed" is one of several dimensions that auxiliary resources can map to, rather than a type in its own right. If we identify the dimensions that can be used to build auxiliary resource types, then we can in using hypermedia ( #270 ), define types in terms of those dimensions.
The four dimensions that I have identify so far are whether an auxiliary resource
As we define the
Link
relation, the type URI itself should resolve to a definition based on these dimensions as well as other data.The text was updated successfully, but these errors were encountered: