It is optional for the repository to expose the definitions of its available node types as content. However, if it does expose these definitions then it should expose them using the built-in node type nt:nodeType (and its associated node types nt:propertyDefinition and nt:childNodeDefinition). These node types are defined to store node type definitions themselves. For example, to store a PropertyDefinition a node of type nt:propertyDefinition is used. It has properties for each of the attributes: the Name is stored in the property jcr:name, the RequiredType in jcr:requiredType and so on.
The attributes that make up a node type definition may in some cases have no set value. For example, some ChildNodeDefinitions may not define a DefaultPrimaryType (this amounts to stating that when such a child node is created by the client the client must provide a valid node type, otherwise an exception will be thrown; no node type will automatically be assumed).
In order to store this information (i.e., the lack of a value) in a nt:nodeType, nt:childNodeDefinition or nt:propertyDefinition node the property representing that attribute must simply be not present, since null values for properties are not allowed (see 4.7.3 No Null Values).
However, to indicate this state in the node type definitions that follow we do use the value null, even though in an in-content representation of the node type this would be represented by the absence of the property in question. For example, in the definition of the node type nt:file,
NodeTypeName
nt:file
Supertypes
nt:hierarchyNode
IsMixin
false
HasOrderableChildNodes
false
PrimaryItemName
jcr:content
ChildNodeDefinition
Name jcr:content
RequiredPrimaryTypes [nt:base]
DefaultPrimaryType null
AutoCreated false
Mandatory true
OnParentVersion COPY
Protected false
SameNameSiblings false
the child node jcr:content must exist (hence Mandatory is true, but it must be added by the client, not automatically (hence AutoCreated is false) and, when created, the client must provide the node type (hence DefaultPrimaryType is null). In an in-content storage of this node type however, the null status of DefaultPrimaryType would be represented by the absence of the property jcr:defaultPrimaryType.
Note that the PrimaryItemName indicator in nt:nodeType works similarly, if there is no primary item specified then the jcr:primaryItemName property of the nt:nodeType node is simply missing. But in the notation used here, this is indicated by specifying a null.
Again, similarly, to indicate that a property or child node definition is residual, the value returned by ItemDefinition.getName() is “*”. However, “*” is not a valid value for the property jcr:name in a nt:propertyDefinition or nt:childNodeDefinition node (because jcr:name it is a NAME property, not a STRING). As a result, an in-content definition of a residual item will simply not have a jcr:name property. In the notation below, however, the indicator “*” is still used.