Blocks (and classes)

We have just seen that we can declare syntactic group of constraints, i.e. groups of constraints built from the same template. But it may be interesting to identify blocks of constraints that are linked together semantically. For example, in a problem model, one may declare a set of constraints that corresponds to clues (typically, for a game), a set of symmetry breaking constraints, a set of constraints related to week-ends when scheduling the shifts of nurses, and so on. This kind of information can be useful for users and solvers. Sometimes, one might also emphasize that there exist some links between variables and constraints.

In XCSP³, there are two complementary ways of managing semantic groups of constraints (and variables): blocks and classes. A block is represented by an XML element whereas a class is represented by an XML attribute. To declare a block of constraints, you just need to introduce an element block, with an optional attribute id. Each block may contain several constraints, meta-constraints, groups of constraints and intern blocks. Most of the times, a block will be tagged by one or more classes (a class is simply an identifier), just by introducing the attribute class as in HTML.

Syntax

<block  [ id="identifier" ]  [ class="(identifier wspace)+" ]>
  (<constraint.../> | <metaConstraint.../> | <group.../> | <block... />)+
</block>

Predefined classes are:

• clues, used for identifying clues or hints usually given for a game,
• symmetryBreaking, used for identifying elements that are introduced for breaking some symmetries,
• redundantConstraints, used for identifying redundant (implied) constraints,
• nogoods, used for identifying elements related to nogood recording.

Other predefined values might be proposed later. It is also possible to introduce user-defined classes (i.e., any arbitrary identifier), making this approach very flexible.

An an illustration, we give the skeleton of an element constraints that contains several blocks. A first block contains the constraints corresponding to some clues (for example, the initial values of a Sudoku grid). A second block introduces some symmetry breaking constraints lex. A third block introduces some redundant constraints. And finally, the two last blocks refer to constraints related to the management of two different weeks; by introducing blocks here, we can associate a note (short comment) with them.

Example

<constraints>
  <block class="clues">
    <intension> ... </intension> 
    <intension> ... </intension>
    ...
  </block>
  <block class="symmetryBreaking">
    <lex> ... </lex> 
    <lex> ... </lex>
    ...
  </block>
  <block class="redundantConstraints"> ... </block>
  <block note="Management of first week"> ... </block>
  <block note="Management of second week"> ... </block>
</constraints>

The class redundantConstraints permits to identify implied constraints that are usually posted in order to improve the solving process. Because they are properly identified (by means of the attribute class), a solver can be easily asked to discard them, so as to compare its behavior when solving an instance with and without the redundant constraints. Note that this facility can be used with any value of class.