The <parameter> definitions correspond directly to setter methods on the classes.
When defining a derived type and overriding a property, the constraints for the property can also be overridden.
Writing Further Constraints
Apart from the built-in constraints that are recognised by the dictionary model parser, further constraints can be added. Implementations need only implement the org.alfresco.service.cmr.dictionary.Constraint interface. Typically, constraints will extend org.alfresco.repo.dictionary.constraint.AbstractConstraint. See the test class org.alfresco.repo.dictionary.constraint.ConstraintsTest for examples of how the constraints can be tested. Note: your custom constraint needs to have a default constructor, as it's used to instantiate it.
To define the constraint in the model, put the fully qualified class name in the type attribute. For example, assume a constraint that only allows multiples of a given number:
Constraint checks are applied during integrity checks, typically at the end of a transaction within the server. All clients are therefore forced to ensure that the constraints are met. How the constraints are enforced varies from client to client. When setting a constraint against a property, it is worth considering how the various repository clients will enforce the constraints.
In the default model, for example, the cm:name property is over-constrained by the REGEX constraint for certain clients - but has to ensure conformance across WebDAV, CIFS, FTP and the Alfresco Web Client. If some of these clients are not being used, then the constraints can be relaxed accordingly.