Structured Views
Overview
A service provider manages a number of containers of resources. These resources are essentially in a flat space. They typically have relationships with each other. These relationships can be quite complex (especially in modelling space).
There are many cases where a client wishes to present all the members of the container in a structured form for a user to browse through. Containers often have a large number of resources (10’s of thousands to millions) and sending them all to a client in one shot is impractical. A client can receive them all through multiple pages, but this too takes time.
What is being proposed here is a way for a client to request a structured view (structured in the sense of parent child relationships and ordering) of a container. A container may have a default view (canonical ownership), or many other defined views. The view is not just an HTML rendering, but rather a progressive way to get resource titles, icons and child resources in a way that a client can build a native UI.
A client can request the contents of a view (which may have a subset of all the resources). If the view is a typical hierarchy, the first page would contain only the top level resources. If a resource in this response has ‘child resources’ in the view, then an additional property with a link to the child resources is available. The client could provide a user gesture to ‘expand’ that resource. The client would then GET the link and populate the tree control on the client. In this way the user is deciding which resources to fetch and populate the structured view.
Here is an example view from the Rational Design Management web UI
And another example of the same tree in the Rational Software Architect desktop client.
The key properties of this view are parent/child relationships and ordering.
Design Requirements
- A structured view of a container of resources should not require changes to be made in the domain of the resources
- Allow multiple, server defined views for a client to select (and request list of)
- Work for large numbers of resources
- Client does not have to have any semantic knowledge of the domain of the resources to build a UI for the user
- Paging rules similar to existing ones (stable/unstable paging)?
Examples
Alternatives Considered
Views are essentially containers. A client can get a list of resource types in container and construct query to get them.
