Java content repositories

Cause i'm interested in JCR (Java Content Repository) technologies, a few months ago I started creating short review of JCR specification (JSR-170).

Maybe someone of you will be interested in this short document. Below you can find first part of my notes:

JCR Name (N,L) where

• ·         N – namespace (empty or valid URI)
• ·         L – local name (String except: ‘.’, ‘..’ (self or parent) and ‘:’, ’*’, ’[‘, ’]’, ’/’, ‘|’

Lexical forms:

• ·         {N}L (expanded name) or
• ·         [prefix:]L (qualified name, where name with prefix has the form prefix:L and name without prefix L)

A qualified name is only interpretable in the context of a namespace mapping, which provides a one-to-one mapping between prefixes and namespaces.

When a JCR name is passed as an argument to a JCR method it may be in either expanded or qualified form. When a repository returns a JCR name it must be in qualified form. The qualified form of a name depends upon the prevailing local namespace mapping of the current session

Two JCR names (N₁, L₁) and (N₂, L₂) are equal if and only if N₁ is equal to N₂ and L₁ is equal to L₂

Every node has an identifier.

·         Identifier form depends on implementation.

·         The identifier of a non-shared node is unique within a workspace. The identifier of a shared node is common to each member of that node's share-set

·         An identifier must be the most stable one available to the implementation.

A JCR path P,

P = (S₀, S₁, ..., S_n),

is an ordered list with at least one element, where each element S_i, for 0 £ i £ n, is a path segment.

A path segment is one of:

• a name segment, (J, I), where J is a JCR name and I is an integer index (I ≥ 1). Segment can occur at any position in a path. The path resolution can return one or more nodes, and cause of this I is the index (1,…,n) of child node denoted by name. If the path resolution returns one node the index can be not used.
•  an identifier segment, U, where U is a JCR identifier. An identifier segment can occur only as the first and sole segment in a path. No other segments may follow an identifier segment.
• the root segment. Segment can occur only as the first segment of a path.
•   the self segment. Segment can occur at any position in a path.
•   the parent segment. Segment can occur at any position in a path.

If the S₀ segment in the path is root or identifier – the path is absolute, otherwise the path is relative to the current node.

The standard path notation:

• /ex:document
• /ex:document/ex:paragraph[2]
• [f81d4fae-7dec-11d0-a765-00a0c91e6bf6]

The extended notation:

• /ex:document[1]
• /ex:document/
• /{http://example.com/ex}document/ex:paragraph[2]

To express JCR names in qualified form, the Namespaces sholud be mapped on prefixes. In XML serialization it is supplied by xmlns attributes  and in a running JCR repository is provided by the local namespace mapping of each individual Session.

The local namespace mapping of a session is determined by the initial set of mappings copied from the namespace registry and any session-local changes made to that set.The namespace registry is a single, persistent, repository-wide table that contains the default namespace mappings

Minimal set of mappings contains:

•   jcr = http://www.jcp.org/jcr/1.0 Reserved for items defined within built-in node types
•  nt = http://www.jcp.org/jcr/nt/1.0 Reserved for the names of built-in primary node types.
• mix = http://www.jcp.org/jcr/mix/1.0 Reserved for the names of built-in mixin node types.
•  xml = http://www.w3.org/XML/1998/namespace Reserved for reasons of compatibility with XML.
•  (the empty string) = (the empty string) The default namespace is the empty namespace.

Every property is of one of the following types: STRING, URI, BOOLEAN, LONG, DOUBLE, DECIMAL, BINARY, DATE, NAME, PATH, WEAKREFERENCE or REFERENCE.

Mapping JCR types to java types:

• ·         STRING - java.lang.String
• ·         URLI – java.lang.String
• ·         BOOLEAN – boolean
• ·         LONG – long
• ·         DOUBLE –double
• ·         DECIMAL - java.math.BigDecimal
• ·         BINARY - javax.jcr.Binary
• ·         DATA - java.util.Calendar
• ·         NAME - properties store instances of JCR names
• ·         PATH - properties store instances of JCR paths and serve as pointers to locations within the workspace.
• ·         WEAKREFERENCE - properties serve as pointers to referenceable nodes by storing their identifiers.
• ·         REFERENCE - properties serve as pointers to referenceable nodes by storing their identifiers.
• ·         UNDEFINED - May be supported by some repositories as a valid property type attribute value in property definitions within node types. In that context it indicates that the specified property may be of any type.

A property may be a single-value or a multi-value property.

A single-value property, if it exists, must have a value. There is no such thing as a null value. A multi-value property can have zero or more values. Again there is no such thing as a null value, however a multi-value property can be empty, just as an array can be empty. The values stored within a multi-valued property are all of the same type and are ordered.

Accessing the value of a property is done with Property.getValue which returns a single Value object. Accessing the set of values of a multi-value property is done through Property.getValues which returns a (possibly empty) array of Value objects.

When the value of a property is read or written using a type different from that declared for the property, the repository attempts a type conversion (see JCR documentation 3.4.6).

Comparsion of values can be implemented in repository and should base on comparsion underlying Java classes methods, in most cases java.lang.String.compareTo (for STRING, URI, WEAKREFERENCE, REFERENCE).

Value.equals() function returns true if values are the same type and equal, are acquaired from the same session and the contents of V1 and V2 have not yet been accessed.

The length of a value is defined as binary length for BINARY properties or as lengths of java.lang.String representations for all other properties.

Node types are used to enforce structural restrictions on the nodes and properties. Every node has one declared primary node type and zero or more mixin node types. Primary node types are typically used to defined the core characteristics of a node, while mixin node types are used to add additional characteristics often related to specific repository functions or to metadata.

Main node type declaration elements:

• mixin. A mixin node type can be assigned to a node during that node's lifetime, not just upon node creation, as is the case with primary node types. The mixin flag is a boolean.
• queryable, meaning that the node type can be used in a query selector. The queryable node type attribute is a boolean.
• declaration child nodes orderable, meaning that for all nodes of that type, the order that the child nodes are iterated over can be programmatically controlled by the user. The orderable child nodes flag is a boolean.
• declaration child items as primary, meaning that for all nodes of that type, that child item is accessible through a dedicated API method which does not require the name of the item. The primary item may be an item name, which must be a JCR name, or null, meaning that there is no primary item.
•  list of property definitions, which specify the properties that nodes of that type are permitted or required to have and the characteristics of those properties
•  list of child node definitions, which specify the permitted or required child nodes and their characteristics.
   

 to be continued ...