Exploring the CQ and its Platform

CQ is an enterprise-grade content management solution with a wide array of powerful features. With this software people in your organization can:

• Build, author and publish websites, complete with enforcement of corporate design and user access control of editing and publishing rights.
• Define and implement workflows for the creation, editing and publishing of content.
• Manage a repository of digital assets such as images, videos and documents, and integrate these assets into your website.
• Use search queries to find content no matter where it is stored in your organization.
• Set up social collaboration tools like blogs, user groups, and calendars.
• Organize your digital assets and web pages using tagging.

All of these things are done through a rich graphical interface accessible through any modern browser, enabling such desktop-like features as in-place editing of text and graphics, drag and drop of page elements and visual design of workflows.

CQ is implemented as a Java web application. It runs in any server that supports the Java Servlet API 2.4 (or higher). CQ comes pre-configured with its own built-in servlet engine, CQSE, but can also be installed in any compatible third-party application server.

Since the system can be accessed from any computer with a modern web browser, no installation of client software is required, so even large installations with thousands of users can be rolled out and upgraded easily.

The web-based user interface uses AJAX to enable a desktop-like user experience. For example, when editing content on a website, authors can drag and drop elements like text paragraph and images right onto the page and see immediately how their changes affect the appearance of the page:

The web-based paradigm even extends to developing on the CQ platform: the system includes a web-based integrated development environment, CRXDE Lite:

The CQ user interface combines the advantages of a web interface with the fluidity and responsiveness usually associated with desktop applications. AJAX (Asynchronous Javascript and XML) technology is used to support interface features such as:

Administration Consoles: The administration consoles for each major CQ function (WCM, DAM, Worklow, etc.) present a consistent "explorer" interface. For example, the WCM console features a two-pane interface with a dynamic expandable/collapsable tree on the left and a grid with draggable rows and columns on the right.

Sidekick: A floating "inspector" window appears on the editable page from which new components can be dragged and actions that apply to the page can be executed.

Content Finder: On the left side of each authorable page, the content Finder provides quick access digital assets such as other images, Flash elements and documents as well as other pages and paragraphs. These items can be dragged to the page to position assets or crteate links to other pages, for example.

In-place Editing: Text components can be edited directly on the webpage without any intervening dialog box or explicit saving.

Drag and drop: Paragraphs other components and digital assets such as images can be positioned on the page simply by dragging and dropping them in the desired location.

Search as you type: Searching for content through the CQ interface presents dynamic matches as you type the query.

Context menu: Right clicking on most onscreen elements brings up a context menu with appropriate action options, just as in a desktop OS interface.

The functionality of CQ is made available through various specialized web consoles:

• Websites for creating and managing multiple websites.
  
• Digital Assets for organizing various digital assets.
  
• Campaigns for managing marketing campaigns.
  
• Community for moderating content of the social network.
  
• Inbox for managing your inbox items.
• Users & Groups for managing user accounts and groups.
  
• Tools for maintaining and configuring the CQ system.
  
• Tagging for organizing tags and their namespaces.
  
• Workflows for modeling and managing workflows.
  
• Reports for creating and monitoring custom usage reports.
  
• Packages for installing, packaging and sharing applications.
  
• Replication for configuring replication agents.
  
• CRXDE Lite for developing applications with a web based IDE.

Each of these web consoles is accessible from the CQ Welcome Page:

To go to an web console, simply click on the appropriate icon. Once you are within a particular console, you can switch to another console using the tabs at the top of the console page.

The Websites console lets you create, view and manage websites running on your CQ instance.Through this console you can create, copy, move and delete website pages, start workflows, and activate (publish) pages. Double clicking on a page icon either in the explorer tree on the left or the inofrmiton grid on the right will take you directly to that page to let you edit it. This console is also referred to as the CQ WCM (Web Content Management) console

For further information, see Authoring Websites in CQ WCM.

The Digital Assets console lets you import and manage digital assets such as images, videos, documents and audio files. These assets can then be used by any website running on the same CQ instance (see above). This console is also referred to as the CQ DAM (Digital Asset Management) console.

For further information, see Working with Digital Assets in CQ DAM

The Users console lets you manage access rights for users and groups. See User Administration and Security.

A workflow is a defined series of steps that describes the process of completing some task. In many cases a number of people are involved in a task and each person must complete their step before handing off the work to the next person.

CQ Workflows allows you to define workflow models by defining the series of steps and the people assigned to complete each step. Once a workflow model is defined, an instance of that workflow can be started. The workflow instance alerts each participant to their assigned task, waits for feedback from the participant (or evidence that the task is completed) and then alerts the next participant, indicating to each person the item to be worked on (a web page for example) and the task to be performed. Alerts can be sent to a participants CQ Workflow inbox, their email account or other noticifaion service.

The Workflow console lets you build workflow models and managing running workflow instances. See Working with Workflows.

The Tagging console lets you administer tags. Tags are short names or phrases that you can use to classify and annotate pieces of content making it easier to find and organize them.

CQ has been developed to maximize compliance with the Web Accessibility Guidelines.

Web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web.

This can include measures such as providing textual alternatives to images (or any non-text item). These can then be used to help people with sight impairment by outputting the text on a braille keypad, or through a voice synthesizer. Such measures can also benefit people with slow internet connections, or indeed any internet user - when the measures offer the user more information.

Such mechanisms must be carefully planned and designed to ensure that they provide the information required for the user to successfully understand and use the content. For example, a text describing an image should not only state what the image is of, but the context in which it is being displayed - a picture of the Earth as seen from outer space can be used to illustrate many themes - space travel, global warming, the oceans, the continents and so on. .

There is a lot of information available about the guidelines on the Internet, including the Web Accessibility Initiative.

Certain aspects are integral to CQ, whereas other aspects must be realized during your project development.

Please see the US 508 Compliance Assessment page for the official status with regard to Section 508 of the US government.

A CQ deployment usually consists of multiple environments, used for different purposes on different levels. A production environment often consists of at least one author instance and one publish instance. Depending on the scale of a project, a production environment may consist of several author and/or publish instances, and at a lower level, the CRX repository may be clustered to several instances as well. Additionally, separate development and test environment levels may also consist of both author and publish instances, mirroring the production environment to a varying extent.

Prior to authors creating and editing their content in CQ, the developers are responsible for developing and customizing the proposed website. They:

• develop and customize components
• realize the design within the website
• develop the necessary scripts to implement the required functionality of the website

Depending on the scale of your system, the development environment can have both author and publish instances, or the test environment will be used for such functionality.

• After development, it is usual to have a Testing environment where you can access the new system, to test both design and functionality.

As mentioned previously, the production (or live) environment consists of at least both:

• an authoring instance for the input of content
• a publish instance for content made available to visitors to the website

Between the different environments, any content, design templates, or customized web application functionality is usually transferred by exporting and importing packages between the different content repositories. Between different instances, content can be directly replicated (copied from destination to source) using a HTTP, or HTTPS, connection.

The replication of content between instances can be configured in detail as an automatic process. For example, content may generally be managed on an author instance and replicated to a publish instance, while public comments on blogs and form submissions may be reverse-replicated from a publish instance back to an author instance, for moderation or other possible workflows.

The following diagram gives an overview of typical configurations possible for a CQ environment. It shows how content flows from the authoring environments until it is available to be accessed by visitors to your website. It also highlights the fact that to increase performance and availability it is common to combine several authoring and publishing environments to service a website.

While different instances in different environments are all installations of the same CQ software installed in different places in the overall system infrastructure, they differ mainly in the way they are configured. For example, it is that configuration which determines whether a CQ instance behaves as an author instance or a publish instance.

Author instances are usually located behind the internal firewall. This is the environment where you, and your colleagues, will perform authoring tasks, such as:

• administrate the entire system
• input your content
• configure the layout and design of your content
• activate your content to the publish environment

Content that was activated is packaged and placed in the author environment's replication queue. The replication process then transports that content to the publish environment.

In order to reverse-replicate data generated in a publish environment back to the author environment, a replication listener in the author environment will poll the publish environment and retrieve such content from the publish environment's reverse-replication outbox.

A publish environment is usually located in the Demilitarized Zone (DMZ). This is the environment where visitors will access your website and interact with it; be it public, or within your intranet.

• holds content replicated from the author environment
• makes that content available to the visitors of your website
• stores user data generated by your visitors, such as comments or other form submissions
• may be configured to add such user data to an outbox, for reverse-replication back to the author environment

The publish environment generates your websites content pages dynamically in real-time and the content can be personalized for each individual user.

To increase availability, and performance, of your Production environment, it is common to combine multiple author and/or publish instances, by either making them available to different groups of users or by load balancing them behind a Dispatcher configuration.

It is also possible to combine multiple instances of the CRX content repository to create a high-availability JCR solution, which can then be integrated with your CQ solution to maximize the protection against hardware and software failure. Such CRX Clusters are supported for various persistence managers. See the CRX Clustering documentation for further information.

The Dispatcher keeps internal statistics about how fast the web servers are processing documents. Based on this data, the Dispatcher estimates which server will provide the quickest response time when answering a request, and so it assigns the necessary request, and computational time, to that server.

You gain:

Increased response time  

In practice this means that the Dispatcher shares document requests between several web servers. Because each server now has fewer documents to process, you have faster response times. The Dispatcher keeps internal statistics for each document category, so it can estimate the server load and distribute the queries efficiently.

Increased fail-safe coverage

If the Dispatcher does not receive responses from a web server, it will automatically relay requests to the other server(s). Thus, if a server becomes unavailable, the only effect is a slowdown of the site, proportionate to the computational power lost. However, all services will continue.

Increased flexibility

You can also manage different websites on the same static web server.

Traditionally, the concepts of baking versus frying are an important distinction between different Web Content Management Systems.  In CMS jargon, "baked" refers to the concept of committing data to static files at publish-time, while "fried" refers to the concept of processing data for final presentation at request-time.

When generating a response on request from a visitor, a content management server can read content from a repository, take user preferences and appropriate access rights into account, before transforming the content into a document that is tailored to the visitor's needs and rights. This allows to provide up-to-date content in real-time in a highly flexible way, but can require significant resources, by demanding more processing power or otherwise causing more computation time, slowing down the response time if many visitors use the system.

When serving a visitor pre-generated static pages, the web server can return that response very quickly, as it can usually be taken directly from memory, at worst it is read from the local drive and served without requiring any further processing. Since these static pages are pre-generated only once, the same content will be delivered for each request and any visitor. This process is very simple, and thus extremely efficient, but does not cater for personalization or dynamic content.

In reality, websites often benefit from a mixture of the two approaches. At its core, CQ processes content dynamically, providing primarily the benefits of a "frying" CMS. By combining this dynamic capability with highly customizable caching rules in the Dispatcher, CQ based web applications can additionally leverage most of the benefits of a "baking" CMS. 

CQ can also be used to generate entirely static content, that can for example be burned to CD-ROM or deployed through web servers, which are physically separate from the content management environment. A limitation of traditional "baked" content management solutions is that the process of generating the static output can require a lot of time and significant resources. By appropriately configuring the caching characteristics of CQ, it can be possible to significantly reduce the time required for running the "baking" process, allowing for shorter turnaround times and more frequent updates of large statically served websites.

The Dispatcher allows to take full advantage of caching and load balancing to achieve an environment that is efficient, fast and dynamic. It works as part of a static HTML server, such as Apache, with the aim of:

• storing (or "caching") as much of the site content as is possible, in the form of a static website.

• accessing the layout engine to retrieve dynamic content as and when necessary, but as little as possible.

Which means that:

• static content is handled with exactly the same speed and ease as on a static web server; additionally you can use the administration and security tools available for your static web server(s).

• dynamic content is generated as needed, without slowing the system down any more than absolutely necessary.

The Dispatcher contains mechanisms to generate, and update, static HTML based on the content of the dynamic site. You can specify in detail which documents are stored as static files and which are always generated dynamically.

Generally, the Dispatcher works on the principle of:

• if the cached document is current, the Dispatcher returns that statically cached version of it immediately

• if the cached document is out of date, the Dispatcher retrieves the current version from the appropriate CQ instance, a step which it can further optimize using Load Balancing

This allows you to take full advantage of a static web server, while retaining the capability to process dynamic content as and when necessary.

Authentication is the process of identifying, and verifying, a user.

The process of authentication and login can be broken down as follows:

1. Authentication information is extracted from the request. In CQ, this is done by an authentication handler.
2. The authentication information is then checked to determine whether it is sufficient and/or correct. In CQ, this is performed by the login modules.
3. The appropriate response is initiated.

CQ performs initial authentication using a standard HTML-login form in conjunction with the HTTP Header Authentication Handler. The HTML form must contain fields for the user name and password (the same field names must then be used by the HTTP Header Authentication Handler).

You can also use a similar form for controlled access to various areas of your website.

The various authentication methods can be realized by using different login modules.

For example, CQ can interact with an LDAP server that stores user information centrally, eliminating the need for duplication. This central server is then used to verify login information which can be used to realize Single Sign On, both with other in-house applications and external Portals.

Authorization determines whether a user is allowed to take action on specific areas within the system. For example, a user can be authorized to read or update a specific page.

Authorization is managed using a series of entities:

User

Users access a system using their user accounts. A user models either a human user or an external system connected to the system. The user account holds the details needed for accessing CQ; a key purpose of an account is to provide the information for the authentication and login processes - allowing a user to log in.

Groups

A group is a collection of users and/or other groups. A change in the permissions/privileges assigned to a group is automatically applied to all users in that group. All users are members of the Everyone group. In addition, users can belong to several other groups. (Even if the group Everyone is deleted, all users remain part of the group because of the indirect relationship between users/groups and authorization. See Privileges for more info.)

CQ Action

CQ actions are performed on a resource. For example, a user can read, edit or delete a page, among other actions.

Permissions

A permission allows a user to perform an action on a given resource within the repository. Permissions are stored, and can be seen, at the resource level within the repository.

Privileges

Privileges allow access to functionality available within the application; for example, replication of a specific path, or the ability to update the page hierarchy (including creating new pages). Privileges are always granted or denied to principals rather than to users or groups. The link between users and groups and the authorization is indirect; there is always a principal associated with a user or group.

Resources

Resources define the functionality to be accessed.

CQ is a powerful software suite designed for managing and delivering content to the web. The major parts of the platform are:

• Java Web Application: CQ is a web application. It can run on any server compliant with the Java Servlet API 2.4 (or higher) and can be accessed using any modern browser. CQ comes pre-configured and bundled with CQSE, Day Software's servlet engine.
• JCR Content Repository: The content in a CQ installation can be stored in any repository compliant with the Content Repository API for Java Technology (JCR). CQ comes pre-configured and bundled with CRX, Day Software's enterprise-grade JCR implementation.
• REST Content Delivery: CQ uses the Apache Sling web application framework to deliver content. This framework is designed to expose a JCR repository over HTTP via a simple but powerful REST API.
• OSGi Application Framework: CQ is built using the OSGi dynamic module system for Java. This allows for different parts of CQ to be stopped, updated and restarted without stopping the entire CQ system itself.
• AJAX User Interface: CQ's web-based interface uses AJAX and other modern browser technologies to enable WYSIWYG editing and formatting of content by authors right on the web page.
  

A web application (or web app) is a program that runs on a remote server and is accessed by users through a web browser. It is usually contrasted with a static website, which is simply a collection of documents that reside on the server and that can be viewed through a browser, over the web. A web application, on the other hand, typically assembles the data to be sent back to the browser, on the fly with each request (or even, using AJAX, between requests). Most modern websites nowadays are essentially web applications. CQ is also a web application, but one that serves as a platform for building other web applications and managing the content that they deliver.

As a Java web application, CQ runs on any server that supports the Java Servlet API . For ease of installation CQ comes bundled with CQSE, Day Software's servlet engine in a Quickstart file that needs only to be double clicked, in order to install and start the server (see deployment)

Since CQ is Java-based it can run on any system for which a Java Runtime Environment is available. This means, for example, that CQ can run on any mainstream operating system, including Windows, Macintosh, Linux, or other flavors of Unix.

CQ is designed to store and retrieve content from any JCR-compliant content repository. In its default configuration, content storage is handled by the CRX repository that comes bundled with CQ. CRX is Day Software's implementation of the JCR standard and the version of CRX that comes with CQ5 supports JCR 2.0.

In addition to CRX, CQ can also work with other JCR repositories, such as Apache Jackrabbit, and with a number of non-JCR data stores, through connectors. Since CQ is built-on top of this standard it is capable of pulling in content not just from its built in CRX repository but from any JCR-compliant source, such as a third-party repository (see, for example, Jackrabbit) or a connector that exposes legacy storage through JCR (see Connectors).

JCR defines a Java API for a class of data storage systems called content repositories. A content repository, as defined by JCR, combines features of a traditional relational database with those of a conventional file system, as well as additional services that content-centric applications often need, but that neither file systems nor databases typically provide. The CRX and JCR section will provide more information on this topic.

Above the JCR repository in the CQ software stack, is the Apache Sling web framework. This framework is designed to expose a JCR content repository through an HTTP-based REST API. Both CQ’s native functionality and the functionality of any website built with CQ are delivered through this framework.

REST (REpresentational State Transfer) refers to the software architectural style on which the World Wide Web is based. It describes the key elements that make the Web work, and so provides a set of principles for how web-based software should be designed. When designing an API to be used over the Web, it therefore makes sense to adhere to these “best practices”.  Apache Sling does just that.

Traditional web application frameworks usually begin servicing a request by selecting a procedure (servlet, script etc.) based on the request URI. This procedure then loads some data, usually from a database, and uses it to construct and send back a response. For example, such a framework might use a URI like this:

http://www.example.com/product.jsp?id=1234

This URI addresses the script to be used to render the result (product.jsp), not the resource that is being requested (product #1234).

Sling turns this around by placing the content at the center of the process. Each content item in the JCR repository is exposed as an HTTP resource, so the request URI addresses the data to be processed, not the procedure that does the processing. Once the content is determined, the script or servlet to be use to handle the request is determined in cascading resolution that checks, in order of priority:

• Properties of the content item itself.
• The HTTP method used to make the request.
• A simple naming convention within the URI that provides secondary information.
  

For example, a Sling application might use a URL like this:

http://www.example.com/cars/audi/s4.details.html

This URL would be decomposed as follows:

• cars/audi/s4 refers to the repository path to the content item (e.g., /content/cars/audi/s4).
• details.html refers to the script to be used to render this content (e.g. /apps/cars/details/html.jsp).

Because a Sling URI addresses content and not presentation logic, such a URI tends to be more meaningful and more stable over time.

CQ is built within an OSGi application framework. OSGi is a dynamic module system for Java that provides a framework within which small, reusable standardized components can be composed into an application and deployed.

These components, called bundles in OSGi parlance, can contain compiled Java code, scripts, content to be loaded in the repository or configuration information. Bundles are loaded and deployed dynamically at runtime during normal operation of the application, enabling, for example, runtime upgrades to CQ without stopping the server.

The implementation of OSGi used by CQ is Apache Felix, which implements OSGi Service Platform Release 4.

CQ's web-based interface uses AJAX and other modern browser technologies to enable WYSIWYG editing and formatting of content by authors right on the web page.

The widget library used by CQ, called ExtJS, provides the highly polished user interface elements that work across all the most importatnt browsers and allow the creation of desktop-grade UI experiences.

These widgets are included within CQ and, in addition to being used by CQ itself, can be used by any website built using CQ.

CQ is built on top of Adobe's CRX platform. CRX is a data storage system specifically designed for content-centric applications. CQ uses this content repository to store all its web content, digital assets, scripts, Java libraries, configuration information and other data.

CRX implements the Content Repository API for Java Technology (JCR). This standard defines a data model and application programming interface (that is, a set of commands) for content repositories. A JCR repository can be thought of as a "super file system". It combines characteristics of conventional file systems with those of relational databases, and adds a number of additional features that content applications often need.

CQ is designed to use any repository compliant with JCR 2.0. By default it uses its internal content repository instance, but it can also be configured to access other JCR-compliant data stores. This includes other content repositories such as Apache Jackrabbit, and legacy storage systems that expose their data through JCR connectors (see Connectors).

A content repository, as defined by JCR, combines features of the traditional relational database with those of a conventional file system.

File system-like features supported by JCR include:

• Hierarchy: Content in a JCR repository can be addressed by path. This is useful when delivering content to the web since most websites are also organized hierarchically.
• Semi-structured content: JCR can store structured documents, like XML, either as opaque files (as a file system would) or as structures ingested directly into the JCR hierarchy.
• Access Control and Locking: JCR can restrict access to different parts of the content hierarchy based on policies or ACLs. It also supports locking of content to prevent conflicts.
  

Database-like features supported by JCR include:

• Query Access: JCR supports querying with languages such as SQL.
  
• Structured Content: JCR can enforce constraints on data structures according to a schema.
  
• Referential Integrity: JCR can enforce referential integrity between content items.
  
• Transactions: Interactions with a JCR repository can be bracketed in transactions and rolled back when needed.

In addition, JCR provides the following services that content-centric applications often need, but that neither file systems nor databases typically provide:

• Unstructured Content: JCR can also support arbitrary dynamic data structures without schema constraints.
• Full-text search: JCR supports full-text search of content.
• Sort order: Items within the hierarchy can maintain their ordering, if desired.
• Observation: API clients can register listeners to react to changes made to the repository.
• Versioning: JCR supports an advanced versioning system for repository content.

For more information, see the JCR specification (in HTML).

Inside a JCR repository, content is organized into one or more workspaces, each of which holds of a hierarchical structure of nodes and properties.

Beginning with the root node at the top, the hierarchy descends much like the directory structure of a file system: each node can have zero or more child nodes and zero or more properties. Properties cannot have children but do have values.

The values of properties are where the actual pieces of data are stored. These can be of different types: strings, dates, numbers, binaries and so forth. The structure of nodes above the properties serves to organize this data according to whatever principles are employed by the application using the repository. Here is a schematic showing a workspace with a simple tree of nodes and properties:

This diagram depicts the content of a workspace W₀ in repository R.

Every node and property in the workspace has a name and every node has an identifier. The names allow each node and property to be addressed by path, much like in file system. For example, above, the property /A/D has as its value the string "Once upon a time..." and the node /A/E has property I which holds a binary property.

The identifier of a node has to be unique within the workspace, so that each node can also be addressed directly by its identifier. For example, above, the node /A/E has the identifier 0004.

The picture above is greatly simplified, to see a more realistic example, you can examine the CRX repository in your CQ installation (remember, CRX is the JCR-compliant repository that CQ is built on top of). Assuming you have administrator access, simply go to the CQ welcome page and click the link CRXDE Lite. This opens the web-based development environment for CQ.

In the top right you will see the name of the workspace that you are logged into:

On the left side the node hierarchy of the workspace is displayed. The node highlighted in the picture below is /content/campaigns:

On the bottom of the screen the properties of the node /content/campaigns are shown:

Notice in the picture above that each of the three properties has a type. In the above example there are three properties jcr:created, jcr:createdBy, jcr:primaryType of types DATE, STRING and NAME, respectively. In fact, there are twelve possible property types in JCR:

• STRING: A piece of text.
• URI: A universal resource identifier.
• BOOLEAN: A boolean value (true or false).
• DATE: A calender date and/or time.
  
• LONG: An integer number.
• DOUBLE: A floating point number.
• DECIMAL: An arbitrary-precision signed decimal number.
• PATH: A path to a node or property.
• NAME: The name of a node, property or other JCR entity.
  
• BINARY: Raw binary data.
• REFERENCE: A reference to another node in the workspace by identifier, that does not permit the removal of the target (it enforces referential integrity).
• WEAKREFERENCE: A reference to another node in the workspace by identifier, that does permit the removal of the target (it does not enforces referential integrity).

Just as properties have types, so do nodes. Looking again at the list of properties of the node
/content/campaigns, above, you will see that one of the properties is jcr:primaryType of type NAME. This property is one of a number of special properties that every node automaticlly has. In this case the property records the name of the node's type: cq:Page.

Every node has a node type that defines what subnodes and properties it can have. Above,the type cq:Page indicates that the node /content/campaigns represents a CQ Page object.

To see the node types registered in your CQ installation's CRX instance you can point your browser to the CRX main console:

http://<your-cq>/crx/index.jsp

For example, in the default installation on your local machine this would be:

http://localhost:4502/crx/index.jsp

(note that you will need administrator access)

The main console page will appear:

Click the Log In link and log in as an administrator (by default the login is admin and the password is admin). Then click on Node Type Administration. This will take you to the following:

This console shows all the regsitered node types in the CRX instance within your CQ install. Note that many of them are prefixed with cq. Since CQ is running on top of CRX, it can be thought of as an application of CRX. The cq node types are those specifically designed for CQ. If another application were using CRX, it would have its own suite of node types.

Scroll down until you see cq:Page in the left pane and click on it. This will reveal the definition of that node type:

For the time being we don't need to go into all the details of this node type definition. The main things to notice are the two subsections entitled Child Node Definitions and Property Definitions. These list the child nodes and properties that a node of type cq:Page is permitted (or required) to have.

Looking first at the Property Definitions, we see that four properties are listed: jcr:created, jcr:createdBy, jcr:mixinTypes and jcr:primaryType. A few things to notice:

• The names of the properties are grayed-out. This indicates that they have been inherited from the definitions of supertypes of cq:Page and are defined in cq:Page itself. This demonstrates an important feature: Node types support inheritance.
• The column called Man indicates whether a property or subnode is mandatory. In the case of the properties listed, only jcr:primaryType is mandatory. That means that every node of type cq:Page must have a property jcr:primaryType (in fact, every node is required to have this property). The other properties are not mandatory, meaning that a node of type cq:Page may have these properties. This demonstrates another feature: Node types can enforce structure.

In the Child Node Definitions we see two entries: a * (asterisk) and jcr:content. The jcr:content entry indicates that a subnode called jcr:content is permitted and that that node must be of type nt:unstructured. The asterisk indicates that any other subnodes may also be added with any types. The main thing to notice here is:

• The * entry indicates that there are no restrictions on subnodes being added to nodes of type cq:Page. This demonstartes another principle of JCR: Node types don't always enforce structure, they can also permit unstructured content.
  

The main features of the JCR repository model are:

• A repository consists of one or more workspaces.
• Each workspace consists of a hierarchy of nodes and properties.
• Nodes and properties can be addressed by path.
• Nodes can also be addressed directly by unique identifiers.
• Properties store the actual content of the repository.
• Nodes provide the structural organization of the content.
• Properties have types.
• Nodes have types.
• A node's type governs which properties and subnodes it may or must have.
• Node types can be used to enforce constraints on content structures.
• But, JCR also supports free-form unstructured content.