JCR Rules for Sakai

Owned by Former user (Deleted)
Last updated: Feb 12, 2008Version comment
2 min read

The Rules for using the JSR-170 API in Sakai are relatively simple. They fall into 2 categories, content and functionality.

Content

If you want to be able to run on many different JCR implementations, both commercial and open source you should only use files and folders, and only attach properties to those files and folders and not any other child nodes. In JCR terms this means using nodes of type nt:folder to represent folders and nt:file to represent files. Nodes of type nt:folder may only contain nt:file nodes or nt:folder nodes. Nodes of type nt:file will contain at single nt:resource node named jcr:content, that will have a standard set of properties as defined in the JSR-170 specification. Properties of the folder or file will be attached to the nt:folder or nt:file nodes. No properties other than those in the JSR-170 specification will be set on ny other node types. For a fuller description of node types and the standard node type schemas please see the JSR-170 specification document. The JCRNodeFactoryService implementation ensures that nodes are created conforming to these rules. By reducing the richness of the Node Type schema, we will be able to support many JCR implementations.

The full RI of JSR-170 allows arbitrary node schemas and types to be created with the same richness as a XML document. Some implementations of the JSR-170 standard do not support this flexibility.

Functionality

Before using any feature of the JSR-170 specification you should check with the JCRService implementation that the underlying JCR Implementation upports the required functionality. Conformance with the JSR-170 standard is defined in levels. As the level of conformance increases, the number of features implemented increases. The license for implementors of the JSR-170 standard stipulates that they must declare their level of conformance and there is an API method that can be used to determine the conformance level supported by the underlying repository. If we find that this API does not supply sufficient granularity we will add extra support in the JCRService APIs.