The system view mapping provides a complete serialization of workspace content to XML without loss of information. In level 1 this allows the complete content of a workspace to be exported (see 6.5 Exporting Repository Content). In level 2, this also allows for roundtripping of content to XML and back again through export and import (see 7.3 Importing Repository Content).
Given a subtree of a workspace, the resulting system view is determined as follows:
The relevant namespace mapping from the repository NamespaceRegistry is included as XML namespace declarations in the top-most XML element (though the xml namespace is excluded, since its presence would be redundant). Additionally a namespace mapping is included that maps to http://www.jcp.org/jcr/sv/1.0, for example xmlns:sv="http://www.jcp.org/jcr/sv/1.0". In what follows it is assumed that the prefix used is sv, though any prefix is allowed as long as it is mapped to the URI above.
Each content repository node becomes an XML element <sv:node>.
Each content repository property becomes an XML element <sv:property>.
The name of each content repository node or property becomes the value of the sv:name attribute of the corresponding <sv:node> or <sv:property> element.
If the root node of a workspace is included in the serialized subtree, it receives the special name jcr:root (instead of the empty string).
The property type of each content repository property is recorded in the sv:type attribute of the corresponding <sv:property> element, using the standard string forms for property type names as returned by the method PropertyType.nameFromValue (i.e., “String”, “Binary”, “Date”, “Boolean”, “Double”, “Long”, “Name”, “Path” and “Reference”).
The value of each non-BINARY content repository property is converted to string form (according to 6.2.6 Property Type Conversion). BINARY values are Base64 encoded. In both cases the resulting string is included as XML text within an <sv:value> element within the <sv:property> element. Entity references are used to escape characters which should not be included as literals within XML text (see 6.4.4 Escaping of Values).
A multi-value property is converted to an <sv:property> element containing multiple <sv:value> elements. The order of the <sv:value> elements reflects the order of the value array returned by Property.getValues.
The hierarchy of the content repository nodes and properties is reflected in the hierarchy of the corresponding XML elements.
Within an <sv:node> element all <sv:property> subelements must occur before the first <sv:node> subelement.
The first two <sv:property> elements within an <sv:node> element must be the jcr:primaryType and jcr:mixinTypes (in that order) properties of the node in question.
In the case of referenceable nodes, the third <sv:property> element in the <sv:node> element must be jcr:uuid.
The order of the <sv:node> subelements of a parent <sv:node> must reflect the order in which the corresponding child nodes are returned by Node.getNodes().