A number of differentmethods in the API transfer node state from one location to another.They often differ in how they treat the identifier of the node. Somemethods always behave the same way in this regard, others havevarious options that control their behavior. The following tablesummarizes the behaviors of the methods.
Method | ReferenceableIdentifiers | Non-referenceableIdentifiers |
Save | Identifiersmustbe preserved, with the possible exception of the first save of anew node (see §3.7.1Identifier Assignment). The state ofa transient node is saved to the persistent node with the sameidentifier. | |
Copy | New identifiersmust be created. | |
Copy | New referenceableidentifiersmust be created. | Newnon-referenceable identifiersmay be created. Thestability of non-referenceable identifiers is a repositoryimplementation variant. |
Move | Referenceableidentifiersmust be preserved. | Non-referenceableidentifiersmay be preserved. The stability ofnon-referenceable identifiers is a repository implementationvariant. |
Clone, Restore | Referenceableidentifiersmust be preserved. On conflict with anexisting node a flag governs whether the existing node is removedor an exception thrown. | |
Update, Merge | Referenceableidentifiersmust be preserved. On conflict with anexisting node, that node is replaced at its existing location inthe target workspace. | |
Import | A flag determineswhether new identifiers are created or incoming ones preserved.On conflict with an existing node the options are to eitherreplace the existing node in place, remove the existing node, orthrow an exception. | |
The following grammardefines the compact node type definition (CND) notation used todefine node types throughout this specification.
Throughout thissection string literals that appear in the syntactic grammardefining CND must be interpreted as specified in §1.3.1StringLiterals in Syntactic Grammars.
In a CND, the presenceof a question mark (“”)indicates that an attribute in question can vary across repositoryimplementations (see §3.7.10Base Primary Node Type and3.7.11Standard Application Node Types).
In the case of thequeryable node type attribute, the absence of an explicit keyword(eitheror)indicates that the attribute is a variant.
Suchvariant nodetype definitions cannot be instantiated in a repository as-is.If an implementation supports a variant node type its node typeregistry must contain a definition of that node type in which eachvariant attribute is resolved to a concrete value.
as a
is assumed. A '?' indicates
The keywords of CND,though defined above as terminal strings with specific cases, are infact case-insensitive. For example,can be written,or even.
The standard Javaescape sequences are supported:
newline
tab
backspace
form feed
return
double quote
single quote
double quote
back slash
Unicode character in hexadecimal
Comments can beincluded in the notation using either of the standard Java forms. Acomment is defined as:
A comment can appearbetween any two valid tokens of the CND grammar. Comments are notdefined within the main CND grammar, but are intended to be strippedduring preprocessing, prior to the actual parsing of the CND.
Vendor-specificextensions are supported through the extension syntax:
Like a comment, anextension can appear between any two tokens of the CND grammar.Extensions are not defined within the main CND grammar, but areintended to be handled during preprocessing, prior to the actualparsing of the CND. The first whitespace-delimited token of theextension should be a unique vendor-specific identifier. Thesemantics of the extension body are implementation-specific.
The notation can becompacted by taking advantage of the following the fact that spacingaround keychars), newlines andindentation are not required. So, the following is also well-formed:
Additionally, thoughspaces are required around the keywords (orderable, mixin, date,mandatory, etc.), short forms for keywords can be used. So, this:
is also well-formed.
Here is a “worst-casescenario” example that demonstrates all the features of thenotation:
1See.
2See.
3See.
4See.
5see.
6See.
7See.
8See§3.11.
9See.
10See the SQL:92 rules for (in ISO/IEC 9075:1992§5.2and).
11See the SQL:92 rules for (in ISO/IEC 9075:1992§5.2and).
12See§4.
13See,,and.
14Seefor more information about the XML Schema list type.
15See,,and.
16This escaping scheme is based on the scheme described in ISO/IEC9075-14:2003 for converting arbitrary strings into valid XML elementand attribute names.
17See.
18See.
19See.
20One common case is a policy that affects both its bound node and thesubgraph below that node. However, any suchdeepnessattribute is internal to the policy and, like any other internalcharacteristic of a policy, opaque to the JCR API except insofar asit is part of the human-readable name and description. Note alsothat, strictly speaking, a policy is not required to affect even itsbound node, though such an implementation would be uncommon.
21Recall thatoutside a transaction persistence of transientstate occurs immediately upon awhile, within a transaction, the effect of anycalls is deferred until commit of the transaction.
22In some systems this feature is called “freeze” or “legalhold” (when the hold is applied due to legal requirements).
23See.