This chapter introduces the principles of defining configuration rules using CDL.
This chapter covers the following topics:
Before defining a rule in CDL, consider the following key questions:
What Model Structure Nodes and Properties Are Participants in the Rule?
What Types of Expressions Define the Relationships or Constraints You Need?
The answer matters because it helps you choose which kind of CDL statement to use. CDL supports explicit and iterator statements. You use explicit statements to express relationships involving specifically named individual nodes or Properties in your Model structure. If you want a set of related nodes (such as all window models of a house) to participate in a series of identical rules, use iterator statements instead of repeating the same rule for each individual node.
If the structure is not static and expected to change often, you may want to define rules that use Properties, rather than explicitly including nodes in the rule’s definition. This reduces the amount of required maintenance whenever the Model structure changes. For more information, see the Oracle Configurator Modeling Guide.
In other words, what type of relationship do you need to define? The answer matters because not all types of relationships can be expressed using CDL.
The available types of constraints and relationships that can be expressed in CDL include Logic, Numeric, Property-based Compatibility, and Comparison. See Kinds of Relationships or Constraints Available in CDL for details.
For information about each type of relation, see Oracle Configurator Developer User's Guide..
Kinds of Relationships or Constraints Available in CDL shows which CDL keywords are used to express which type of relationship. For example, to define a Numeric constraint that contributes a value of 10 to Total X when Option A is selected, use the CONTRIBUTE and TO keywords.
The table below shows the available Rule Types and CDL keywords available in CDL.
Important: There is new functionality available for CDL when using the Fusion Configurator Engine (FCE). The FCE is an alternative to the configuration engine described in this document. For all information about CDL with the FCE, see the Oracle Configurator Fusion Configurator Engine Guide.
This section provides an overview of how the syntax, semantics, and lexical structure of a rule written in CDL relate to one another. This section contains the following topics:
For details about converting an existing rule to a Statement Rule as a way to study CDL, see Oracle Configurator Developer User's Guide.
A configuration rule has a name, associated Model, definition, other attributes such as Effectiveness and Usage, and optionally a description. The rule definition can be written in CDL and consists of whitespace characters, comments, and one or more individual statements that express the intent of the rule.
When creating a Statement Rule in Oracle Configurator Developer, you enter the name and description in input fields and the rule definition in the text box provided for that purpose.
For more information about entering rule definitions in Oracle Configurator Developer, see the Oracle Configurator Developer User's Guide.
Statements define the rule’s intent, such as to contribute a value of 10 to Total X when Option A is selected.
Multiple statements in a rule definition must be separated from one another with semi-colons (;). CDL supports two kinds of statements: Explicit and Iterator. For more information, see CDL Statements.
CDL statements are parsed as tokens; everything in CDL is a token, except whitespace characters and comments. For more information about how CDL is parsed, see Validation of CDL.
Statements consist of one or more clauses. Clauses consist of keywords and one or more expressions. Keywords are predefined tokens that determine CDL syntax and make it more readable and easy to use. CONSTRAIN and CONTRIBUTE are examples of keywords.
An expression is the part of a statement that contains an operator and the operands involved in a rule operation. An operator is a predefined keyword, function, or character that involves the operands in logical, functional, or mathematical operations. REQUIRES and the plus sign (+) are examples of operators. Operands are also called rule participants. An operand can be an expression, a literal, or an identifier. The literal or identifier operand can be present in the rule as a singleton or as a collection.
Literals are tokens of a specific data type, such as Numeric, Boolean (True or False), or Text. An identifier is a token that consists of a sequence of letters and digits. Identifiers identify Model objects or formal parameters. When an identifier identifies a Model object it refers to a Model node or Property and the sequence of letters and digits starts with a letter. These kinds of identifiers are called references. When an identifier is a formal parameter, it identifies a local variable and is used in an iterator statement. Formal parameters are a sequence of letters and digits prefixed with an ampersand (&).
For greater readability and to convey meaning such as the order of operations, CDL supports separators. Separators are tokens that maintain the structure of the rule by establishing boundaries between tokens, grouping them based on some syntactic criteria. Separators are single characters such as the semi-colon between statements or the parentheses around an expression.
For more information about these statements and the CDL elements they contain, see CDL Statements. For help with determining the CDL elements that correspond to particular rules, assemble a Logic, Numeric, Compatibility, or Comparison rule interactively in Oracle Configurator Developer, and then convert it to a Statement Rule. When you do this, Configurator Developer displays the rule’s current definition in CDL. You can then expand or enhance the rule by typing additional statements, keywords, identifiers, structure node names, and so on.
Comments are included in rule definitions at your discretion to explain the rule. Whitespace, which includes spaces, line feeds, and carriage returns, format the input for better readability. See Comments and Whitespace and Line Terminators for details.
Keywords are not case sensitive.
Keyword operators are not case sensitive.
Model object identifiers are case sensitive.
Formal parameters are case sensitive and cannot be in quotes.
The constants E and PI as well as the scientific E are not case sensitive.
The keywords TRUE and FALSE are not case sensitive.
Text literals are case sensitive.
All keywords, constant literals, and so on are not case sensitive.
Note: Operands are not case sensitive with the exception of Model object identifiers (node names), formal parameters or variables, User Property names, and text literals.
Model structure nodes that have the same name as a keyword must be quoted when referred to in CDL
Following are valid data types when defining a rule in CDL:
Under certain circumstances, a data type of a variable is not compatible with the type expected as an argument. The Oracle Configurator parser does not support explicit conversion or casting between the data types. The parser performs implicit conversion between compatible types. See Implicit Conversion of Data Type for details.
If a rule definition has wrong data types, the parser returns a type mismatch error message. Invalid Collection shows a collection whose data types cannot be implicitly converted to be compatible.
The table Implicit Conversion of Data Type shows which data type each source data type implicitly converts.
| Source data type (or collection of the same type) |
Implicitly converts to (or collection of the same type) |
|---|---|
| INTEGER | DECIMAL |
| NODE of type BOM Standard Item, BOM Option Class, BOM Model, Option Feature, Option, or Boolean Feature | BOOLEAN INTEGER DECIMAL Node type |
| NODE of type Integer Feature | INTEGER DECIMAL |
| NODE of type Decimal Feature | DECIMAL |
| NODE of type Text Feature | TEXT |
Unless specified otherwise, all references to matching types throughout this document assume the implicit data type conversions.
Note: Although TEXT is included as a data type here, it can only be used in a static context. You cannot use a TEXT literal, reference, or expression in the actual body of a CONSTRAINT or CONTRIBUTE expression. The Oracle Configurator compiler validates this condition when you generate logic for the Model.