Overview

Here are some recommendations for naming nodes, that have worked well for us in the context of Sling and other JCR-based applications.

The main goal is to keep the transparency of JCR - good node names will help make your content structure obvious.

Node naming recommendations

Nodes

Use all lower case for node names.

Separate words using dashes/hyphens instead of underscores (_), e.g. funky-content. This is in line with the general recommendations for SEO (search engine optimization).

Short unixish names work well, especially at the top of the hierachy, and the Filesystem Hierarchy Standard is good inspiration for a JCR content hierarchy.

If several nodes share a common prefix or suffix, it might be a sign that they belong in a folder with a descriptive name. If you have business-rule-foo and business-rule-bar for example, business-rule/foo and business-rule/bar probably makes sense, with an additional hierarchy level.

Properties

Use camel{{`Case for property names, e.g. }}lastModifiedBy`.

Short but clearly understandable property names are good, don't be too cryptic here. Property names are always the last element of a path, so it's not that bad if they are a bit longer.

Namespaces

Use namespaces with care, they are usually only required for infrastructure code. The sling:resourceType property name is a good example, it's a Sling-specific thing and you don't want collisions with a user-defined resourceType property.

Do not use the reserved namespaces and prefixes (jcr:, nt:, mix:, rep:, sv:, xml:, xmlns: etc.) for node names that are not predefined by the spec. And don't use namespaces from another library, e.g. sling: in a an application on top of sling.

Node type names

Local name starts with an uppercase. For example: sling:Resource. (JCR spec is an exception here with node types all lower case, eg. nt:file).

Mixins, if they denote a special attribute or ability for a node, might be named accordingly with an "-able" suffix: rep:AccessControllable