Standards » TMCL

applies-to is optional for user defined constraints.
define both require and deny

Have written into the draft both denial-constraint and requirement-constraint. However, the issue of whether user-defined constraints should be global or local has not been resolved.

All local constraints (that is, constraints which apply to some topic/association/whatever type and where the query uses $this to refer to the topic/association/whatever being constrained) can be formulated as global queries. So in terms of expressivity there is no real need for local constraints.

However, if a system is doing continuous validation of a topic map (either via events after each commit, or in an editing environment) all global constraints will need to be checked after every change (and run globally, which is hard on the query processor). Local constraints, however, need only be checked if a topic/association/whatever of the right type has been modified. This is much cheaper, especially as the query will only verify the given topic (as opposed to all topics of that type).

The difficulty with specifying these constraints is that we use different association types to connect to topics of different type. There is constrained-topic-type, constrained-statement, and constrained-role-type.

1. Allow user-defined-constraints to use any one of these three association types. This cannot be enforced by the TMCL meta-schema unless we use a user-defined constraint.
2. Allow only constrained-topic-type, since any statement/role must be reachable that way, anyway, and constraints can in the worst case be formulated as global constraints.
3. Create a new applies-to association type which can go to topic types, statement types, and role types.
4. Do not support local constraints.

The Seattle meeting considered this, and came to the conclusion that local constraints should not be supported.

Spec now updated to reflect this.