The guiding principles governing the design of the API are:
It should not be tied to any particular underlying architecture, data source or protocol.
The API is, of course, essentially a set of Java interfaces, which can be implemented in a wide variety of ways. Hence, achieving this goal is not difficult in itself. The main challenge here is to allow enough flexibility in the API so that it can be used for both hierarchical and non-hierarchical repository models. This is done by providing for both hierarchical, path-based addressing of content items and direct, UUID-based addressing.
It should be easy to use from the programmer’s point of view.
To this end, the API is designed to be as simple and straightforward as possible. In particular, it has a simple object model and concentrates on representing the core functionality of a content repository without venturing into areas that might be regarded as “content applications”.
It should allow for relatively easy implementation on top of as wide a variety of existing content repositories as possible.
A concerted effort was made to ensure that it would be relatively easy to implement the API (especially at level 1, see below) on top of the repositories of most major vendors.
However, it should also standardize some more complex functionality needed by advanced content-related applications.
Recognizing that a tension exists between this aim and the previous one, this specification has been split into two compliance levels as well as a set of optional features.
Level 1 defines a read-only repository. This includes functionality for the reading of repository content, introspection of content-type definitions, basic support for namespaces, export of content to XML and searching. This functionality should meet the needs of presentation templates and basic portal applications comprising a large portion of the existing code-base of content-related applications. Level 1 is also designed to be easy to implement on top of any existing content repository.
Level 2 additionally defines methods for writing content, assignment of types to content, further support for namespaces, and importing content from XML.
Finally, a number of independently optional features are defined that a compliant repository may support. These are transactions, versioning, observation, access control, locking and additional support for searching.