This chapter presents detailed information about the elements of CDL.
For an overview of CDL elements, as well as details about case sensitivity and quotation marks, see Anatomy of a Configuration Rule Written in CDL.
For syntax abstracts, see Notation Used in Presenting CDL Grammar.
This chapter covers the following topics:
A rule definition written in CDL consists of one or more statements that define the rule’s intent. The two kinds of statements are:
The difference between explicit and iterator statements is in the types of participants involved.
Explicit statements express relationships among explicitly identified participants and restrict execution of the rule to those participants and the Model containing those participants.
In an explicit statement, you must identify each node and Property that participates in the rule by specifying its location in the Model structure. An explicit statement applies to a specific Model, thus all participants of an explicit statement are explicitly stated in the rule definition.
CDL supports several kinds of explicit statements, which are identified by the keywords CONSTRAIN, CONTRIBUTE, and COMPATIBLE.
See Notation Used in Presenting CDL Grammar for the syntax definition of statements.
Constraint Statements with the CONSTRAIN Keyword, shows such an explicit statement consisting of a single expression of the logical implies relation.
See Expressions for more information about the precise syntax of explicit statements.
Iterators are query-like statements that iterate, or repeat, over elements such as constants, Model references, or expressions of these. Iterators express relations among participants that are Model node elements of a collection or participants that are identified by their Properties and allow the rule to be applied to Options of Option Features with the same Properties. Iterators allow you to use the Properties of Model nodes to specify the participants of constraints or contributions. This is especially useful for maintaining persistent sets of constraints when the Model structure or its Properties change frequently. Iterators can also be used to express relationships between combinations of participants, such as with Property-based Compatibility Rules.
Iterator statements can use local variables that are bound to one or more iterators over collections. This is a way of expressing more than one constraint or contribution in a single implicit form. During compilation, a single iterator statement explodes into one or more constraints or contributions. See COLLECT Operator for more information.
The available iterators that make a rule statement an iterator statement are:
See Notation Used in Presenting CDL Grammar for the syntax definition of statements.
Constraint Statement with the FOR ALL...IN Iterator shows an iterator statement consisting of a single expression of the logical Defaults relation and the iterator.
See Expressions for more information about the precise syntax of kinds of iterator statements.
For an additional example of a rule statement that contains an iterator, see Example Iterator Statement in CDL.
The syntax of the FOR ALL clause allows for multiple iterators. The statement can be exploded to a Cartesian product of two or more collections.
Multiple Iterators in One CONSTRAIN Statement, is an example of a Cartesian product as the rule iterates over all the Options of the Tint Feature in the Glass Component and over all the Options of the Color Feature in the Frame Component of the Window Model in Example House Model. Whenever the Stain Property of the Color Options equals the Stain Property of the Tint Options, the selected color pushes the corresponding stain true. So, for example, when &color.Property ("stain") and &tint.Property ("stain") both equal Clear, selecting the White Option causes the Clear Option to be selected.
Multiple Iterators in One CONSTRAIN Statement
CONSTRAIN &color IMPLIES &tint
FOR ALL
&color IN OptionsOf(Frame.Color),
&tint IN OptionsOf(Glass.Tint)
WHERE &color.Property ("stain") = &tint.Property ("stain");
The difference between this and a Property-based Compatibility Rule is that Multiple Iterators in One CONSTRAIN Statement selects participants without over constraining them, while a compatibility test deselects participants that do not pass the test. For more information on designing rules and the impact on performance, see Alternative Rule Designs.
In Multiple Iterators in One CONTRIBUTE...TO Statement, the numeric value of Feature a contributes to Feature b for all the Options of a and b when the value of their Property Prop2 is equal.
Multiple Iterators in One CONTRIBUTE...TO Statement
CONTRIBUTE &var1 TO &var2
FOR ALL &var1 IN {OptionsOf(a)}, &var2 IN {OptionsOf(b)}
WHERE &var1.Property("Prop2") = &var2.Property("Prop2");
An expression is part of a CDL statement. It has two operands that are connected by an operator, or functions and their arguments. See Notation Used in Presenting CDL Grammar for the syntax definition of expressions. See Operators, Operands, and Functions for details.
Simple Mathematical Expression in a CDL Rule shows a simple mathematical expression where the two operands are 2 and frame.border, and the operator is * (multiplication).
Simple Mathematical Expression in a CDL Rule
2 * frame.border
Nested Mathematical Expression in a CDL Rule shows a simple mathematical expression of Simple Mathematical Expression in a CDL Rule used as the second operand in another expression, where the first operand is window.frame.width and the operator is - (subtraction).
Nested Mathematical Expression in a CDL Rule
window.frame.width - 2 * frame.border
See Operator Precedence for details about the precedence of operators.
For an example of CDL rules using these expressions, consider the Window Model in Example Explicit Statement in CDL. If you want to calculate the size of the glass to be put into a window frame where the glass is inserted in the frame 1/2 inch at each side, and the frame border is 1 inch, you might write the two Contributes To rules in Mathematical Expressions in Rule Statements.
Mathematical Expressions in Rule Statements
CONTRIBUTE window.frame.width - 2 * frame.border + 2 * 0.5 TO glass.width; CONTRIBUTE window.frame.height - 2 * frame.border + 2 * 0.5 TO glass.height;
Following are some additional examples of expressions.
Expressions Resulting in a BOOLEAN Value
a > b a AND b (a + b) * c > 10 a.prop LIKE "%abc%"
Expressions Resulting in an INTEGER or DECIMAL Value
a + b ((a + b) * c )^10
Keywords consist of Unicode characters and are predefined identifiers within a statement. Model structure nodes with the same name as a CDL keyword, must be enclosed in quotes when used in CDL. For example: Contribute 'Contribute' To B.
Keywords include the following:
See Keyword Symbols for the syntax definition of these keywords in expressions.
The CONSTRAIN keyword is used at the beginning of a constraint statement. A constraint statement uses an expression to express constraining relationships. You can omit the CONSTRAIN keyword from a constraint statement.
Each constraint statement must contain one and only one of the following keyword operators:
For a description of these constraints, see the section on Logic Rules in the section on logical relationships, Oracle Configurator Developer User's Guide.
Constraint Statements with the CONSTRAIN Keyword and Constraint Statements Without the CONSTRAIN Keyword show constraint statements with and without the CONSTRAIN keyword.
Constraint Statements with the CONSTRAIN Keyword
CONSTRAIN a IMPLIES b; CONSTRAIN (a+b) * c > 10 NEGATES d;
Constraint Statements Without the CONSTRAIN Keyword
a IMPLIES b; (a + b) * c > 10 NEGATES d;
Constraint Statement with the FOR ALL...IN Iterator expresses that if one Option of Feature F1 is selected, then by default select all the rest of the Options. See Alternative Rule Designs for other examples of a CONSTRAIN statement with a FOR ALL iterator.
Constraint Statement with the FOR ALL...IN Iterator
CONSTRAIN F1 DEFAULTS &var1 FOR ALL &var1 IN F1.Options();
Unlike constraint statements, contribute statements contain numeric expressions. In a contribute statement, the CONTRIBUTE and TO keywords are required. See Notation Used in Presenting CDL Grammar for the syntax definition of these keywords in expressions.
CONTRIBUTE...TO Statements
CONTRIBUTE a TO b; CONTRIBUTE (a + b) * c TO d;
CONTRIBUTE...TO is the CDL representation of the Numeric Rule in Oracle Configurator Developer.
For a description of a Contributes to rule, see the section on Numeric Rules, Oracle Configurator Developer User's Guide.
Plan carefully when writing rules with decimal operands and BOM Option Classes, or collections. The table CONTRIBUTE A TO B where B is a BOM Option Class or a Collection explains what action should be taken when A contributes to B and B is either a BOM Option Class with multiple options, or B is a collection. The columns are If, AND, and Then.
| If | AND | Then |
|---|---|---|
| A resolves to a decimal | Option 1 and Option 2 are both integers | Use the Round() function on A |
| Option 1 and Option 2 are both decimals | No further action is needed on A | |
| Option 1 is decimal and Option 2 is integer | Use Round() function on A to meet the most limiting restriction - Option 2 an integer. | |
| A is an integer | Option 1 and Option 2 are both integers | No further action is needed on A |
| Option 1 and Option 2 are both decimals | ||
| Option 1 is decimal and Option 2 is integer |
The COMPATIBLE keyword is used at the beginning of a compatibility statement that defines compatibility based on Property values between Options of different Features, Standard Items of different BOM Option Classes, or between Options of a Feature and Standard Items of a BOM Option Class. COMPATIBLE...OF is the CDL representation of a Property-based Compatibility Rule in Oracle Configurator Developer.
A Compatibility statement requires the keyword COMPATIBLE and two or more identifiers. The syntax of COMPATIBLE...OF is essentially the same as that of FOR ALL....IN. For each formal identifier in the COMPATIBLE clause, there must be a matching identifier in the OF clause. The conditional expression determining the set of desired combinations is in the WHERE clause.
The CDL of a Property-based Compatibility must include at least two iterators. For additional information about using a WHERE clause, see WHERE.
In Property-based Compatibility Rule, the rule iterates over all the Options of the Tint Feature in the Glass Component and over all the Options of the Color Feature in the Frame Component of the Window Model in Example House Model. A color and tint are compatible whenever the Color Option’s Stain Property equals the Tint Option’s Stain Property.
Property-based Compatibility Rule
COMPATIBLE
&color OF Frame.Color,
&tint OF Glass.Tint
WHERE &color.Property("stain") = &tint.Property("stain");
For a description of Compatibility, including order of evaluation, see the section on Property-based Compatibility Rules, Oracle Configurator Developer User's Guide.
See Notation Used in Presenting CDL Grammar for the syntax definition of these keywords in expressions.
The FOR ALL and IN keywords begin the two clauses of an iterator statement. The IN keyword specifies the source of iteration
Note: The IN clause can contain only literal collections or collections of model nodes, such as OptionsOf. There is no specification of instances, so all instances of a given Model use the same iteration.
See Notation Used in Presenting CDL Grammar for the syntax definition of these keywords in iterator expressions.
In FOR ALL ... IN ... Clause, the result is 3 contributions to option d.
CONTRIBUTE &var TO d
FOR ALL &var IN {a, b, c};
In FOR ALL ... IN ... and WHERE Clause using Node Properties, the result is as many contributions to Feature d as there are children in Feature a, whose Property prop3 is less than 5. This example also shows a collection enclosed in braces (see Collection Literals).
FOR ALL ... IN ... and WHERE Clause using Node Properties
CONTRIBUTE &var.Property("NumProp") + 10 TO d
FOR ALL &var IN {OptionsOf(a)}
WHERE &var.Property("prop3") < 5;
In both examples, a single statement explodes into one or more constraints or contributions without explicitly repeating each one. In both examples, the iterator variable can also participate in the left hand side of the contribute statement.
The WHERE keyword begins a clause of an iterator statement that acts as a filter to eliminate iterations that do not match with the WHERE criteria.
See Notation Used in Presenting CDL Grammar for the syntax definition of this keyword in iterator expressions.
In FOR ALL ... IN ... and WHERE Clause using Node Properties, the result is only as many contributions to option d as there are children in the criteria specified in the WHERE clause.
Note: The conditional expression in the WHERE clause must be static. When using the COLLECT operation in a WHERE and an IN clause, the operands must be static. All User Properties on nodes and all constants are static operands. As a result, operands in the WHERE clause of a COMPATIBLE...OF statement can only be Properties.
Note: Configurator Developer evaluates Property-based Compatibility Rules from the top down, and gives no priority or precedence to an expression based on its use of the AND or OR operator. In other words, the system evaluates the first relation you enter, followed by the second, and so on.
The COLLECT keyword is used exclusively as an operator. For details about the COLLECT keyword, see COLLECT Operator.
Operators are predefined tokens consisting of Unicode characters to be used as the expression operators among the expression operands. An operator specifies the operation to be performed at runtime between the operands. This section includes the following topics:
Important: There are new operators 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.
See Notation Used in Presenting CDL Grammar for the syntax definition of operators. Operators Listed by Type lists the predefined operators supported by CDL.
The table Operators Listed by Type lists the predefined operators supported by CDL and includes all operator types, their available operators, and a description of each. Comparison types include comparing a numeric valued Feature with a property of a selected Option, or comparing a Property value with the name of an Option.
| Operator Type | Operators | Description |
|---|---|---|
| Logical | AND | AND requires two operands and returns true if both are true. |
| Logical | OR | OR requires two operands and returns true if either is true. |
| Logical | NOT | NOT requires one operand and returns its opposite value: false if the operand is true, true if the operand is false. |
| Logical | NotTrue | NotTrue requires one operand and returns true if its logic state is false or unavailable. For additional information about using NotTrue, see the Oracle Configurator Modeling Guide. |
| Logical | REQUIRES | REQUIRES requires two operands. See the Oracle Configurator Developer User’s Guide for details. |
| Logical | IMPLIES | IMPLIES requires two operands. See the Oracle Configurator Developer User’s Guide for details. |
| Logical | EXCLUDES | EXCLUDES requires two operands. See the Oracle Configurator Developer User’s Guide for details. |
| Logical | NEGATES | NEGATES requires two operands. See the Oracle Configurator Developer User’s Guide for details. |
| Logical | DEFAULTS | DEFAULTS requires two operands. See the Oracle Configurator Developer User’s Guide for details. |
| Logical and Comparison | LIKE | LIKE requires two text literal operands and returns true if they match. See LIKE and NOT LIKE Operators for restrictions. |
| Logical and Comparison | NOT LIKE | NOT LIKE requires two text literal operands and returns true if they do not match. See LIKE and NOT LIKE Operators for restrictions |
| Logical, Arithmetic, and Comparison | = | Equals requires two operands and returns true if both are the same. |
| Logical, Arithmetic, and Comparison | > | Greater than requires two operands and returns true if the first is greater than the second. |
| Logical, Arithmetic, and Comparison | < | Less than requires two operands and returns true if the first is less than the second. |
| Logical, Arithmetic, and Comparison | <> | Not equal requires two operands and returns true if they are different. |
| Logical, Arithmetic, and Comparison | <= | Less than or equal to requires two operands and returns "true" if the first operand is less than or equal to the second. |
| Logical, Arithmetic, and Comparison | >= | Greater than or equal requires two operands and returns "true" if the first operand is greater than or equal to the second. |
| Arithmetic | * | Performs arithmetic multiplication on numeric operands. |
| Arithmetic | / | Performs arithmetic division on numeric operands. |
| Arithmetic | - | Performs arithmetic subtraction on numeric operands. |
| Arithmetic | + | Performs arithmetic addition on numeric operands. |
| Arithmetic | ^ | Performs arithmetic exponential on numeric operands. |
| Arithmetic | % | Performs arithmetic modulo on numeric operands. |
| Text | + | Performs a concatenation of text strings. See Text Concatenation Operator for restrictions. |
| Other | ( ) , . - | parentheses ( ) are used to group sub-expressions comma (,) is used to separate function arguments dot (.) is used for referencing objects in the Model tree structure unary minus (-) is used to make positive values negative and negative values positive. |
The result of each expression operator can participate as an operand of another operator as long as the return type of the former matches with the argument type of the latter.
See Data Types for more information about allowable data types of operands.
The table Mapping of Operators and Data Types lists the basic return data types of each operator.
| Operator(s) | Data type |
|---|---|
| Arithmetic | INTEGER, DECIMAL |
| Logical | BOOLEAN |
| Comparison | BOOLEAN |
Operators are processed in the order given in the following table. Operators with equal precedence are evaluated left to right.
The table Precedence of Operators lists the precedence of expression operators in CDL. The columns are Operator, Precedence (direction), and Description.
Although LIKE and NOT LIKE are included as text relational operators, they can only be used in static context; for example, the WHERE clause of iterators. As with any TEXT data type, you cannot use LIKE and NOT LIKE with runtime participants unless it evaluates to a constant string. Oracle Configurator Developer validates this condition when you generate logic.
LIKE Expression Resulting in a BOOLEAN Value
a.prop LIKE "%eig%"
A TRUE result is returned if the text of a.prop contains the characters ’eig’, such as a.prop =’weight’ or ’eight’. FALSE is returned if the text of a.prop=’rein’. For more information on the LIKE operator and the use of wildcards, see the section on Property-based Compatibility Rules in the Oracle Configurator Developer User’s Guide.
In the following example, selecting option A and B implies that options within C are selected when the value of their associated Property is "A1B1".
LIKE Expression that Selects Options Based on a Property Value
Constrain Alltrue('A','B') implies &C
for all &C in {optionsof('C')}
where &C.property("AB Compatibility") like "A1B1"
In the example below, selecting option A and B implies that options within C are selected when the value of their associated Property is something other than "A1B1".
NOT LIKE Expression that Selects Options Based on a Property Value
Constrain Alltrue('A','B') implies &C
for all &C in {optionsof('C')}
where not (&C.property("AB Compatibility") like "A1B1" )
For a list of comparison operators, see Operators Listed by Type.
Although "+" is included as a text concatenation operator, it can only be used in static context; for example, the WHERE clause of iterators. As with any TEXT data type, you cannot use text concatenation in the actual body of a constrain or contributor statement unless it evaluates to a constant string. Oracle Configurator Developer validates this condition when you generate logic.
A collection of values can be created using an aggregation function such as Min(...), Max(...), Sum(...), AnyTrue(...). An iterator can use the COLLECT operator to specify the domain of the collection that is passed to the aggregation function. In many cases FOR ALL serves that purpose. COLLECT Operator, Single Contribution shows a single contribution of the maximum value of the collection of children of Feature a using a COLLECT operator and a FOR ALL iterator.
COLLECT Operator, Single Contribution
CONTRIBUTE Max({COLLECT &var FOR ALL &var IN {OptionsOf(a)}}) TO d;
has the same result as
CONTRIBUTE Max &var TO d
FOR ALL &var IN {OptionsOf(a)} ;
The COLLECT operator is necessary when limiting an aggregate. COLLECT Operator, Single Contribution shows a rule where the iteration of the FOR ALL and WHERE clauses result in an error for every element of the collection {Option11, Option32, OptionsOf(Feature1)} that does not contain the Property P1.
COLLECT Operator, Single Contribution
CONSTRAIN &varA IMPLIES Component.Featuure.Option
FOR ALL &varA IN {Option11, Option32, OptionsOf(Feature1)}
WHERE &varA.Property("P1") = 5;
COLLECT Operator Contributions uses COLLECT, which prevents the error.
COLLECT Operator Contributions
CONSTRAIN &varA IMPLIES Component.Feature.Option
FOR ALL &varA IN {Option11, Option32, {COLLECT &varB
FOR ALL &varB IN OptionsOf(Feature2)
WHERE &varB.Property("P1") = 5}};
COLLECT can be used in any context that expects a collection. The COLLECT operator can be used along with a complex expression and a WHERE clause for filtering out elements of the source domain of the collection. See WHERE for more information.
Since COLLECT is an operator that returns a collection, it can also be used inside of a collection literal, as long as the collection literal has a valid inferred data type. The Oracle Configurator compiler flattens the collection literal during logic generation, which allows collections to be concatenated. See Collection Literals for details.
The COLLECT operator can have only one iterator, because the return type is a collection of singletons. CDL does not support using a Cartesian product with the COLLECT operator.
The COLLECT operator cannot put dynamic variables in the IN and WHERE clauses, as this may result in a collection that is unknown at compile time. For additional information, see WHERE.
The COLLECT operator can use the DISTINCT keyword to collect distinct values from a Property, as shown in COLLECT Operator with DISTINCT, which prevents the selection of options having different values for the Property Shape from the Option Feature Feature3. Feature3 has zero Minimum Selections and no limit on Maximum Selections.
COLLECT Operator with DISTINCT
AnyTrue({COLLECT &opt1
FOR ALL &opt1 IN {'Feature3'.Options()}
WHERE &opt1.Property("Shape") = &shape})
EXCLUDES
AnyTrue({COLLECT &opt2
FOR ALL &opt2 IN {'Feature3'.Options()}
WHERE &opt2.Property("Shape") <> &shape})
FOR ALL &shape IN
{COLLECT DISTINCT &node.Property("Shape")
FOR ALL &node IN 'Feature3'.Options()}
In addition to operators, expressions can also contain functions, which may take arguments and return results that can be used in the rest of the expression. All standard mathematical functions are implemented in CDL.
The result of each function can participate as an operand of another operator or function as long as the return type of the former matches with the argument type of the latter.
Functions perform operations on their arguments and return values which are used in evaluating the entire statement. Functions must have their arguments enclosed in parentheses and separated by commas if there is more than one argument. Function arguments can be expressions.
For example, both of the following operations have the correct syntax for the Round function, provided that Feature-1 and Feature-2 are numeric Features:
Round (13.4) Round (Feature-1 / Feature-2)
CDL supports the following functions:
This section also contains information about Function Overflows and Underflows.
Important: There are new functions 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.
The table Arithmetic Functions lists the arithmetic functions that are available in CDL. The term infinity is defined as a number without bounds. It can be either positive or negative. The columns are Function and Description.
The table Trigonometric Functions lists the trigonometric functions that are available in CDL. The columns are Function and Description.
The table Logical Functions lists the logical functions that are available in CDL. The columns are Function and Description.
The table Set Functions lists the set functions that are available in CDL. The columns are Function and Description.
Although the Text functions are included here, they can only be used in static context; for example the WHERE clause of iterators.
Note: As with any TEXT data type, do not use a text function in the body of a CONSTRAINT or CONTRIBUTE statement unless it evaluates to a constant string. The compiler validates this condition.
The table Text Functions lists the text functions that are available in CDL. The columns are Function and Description.
In addition, several functions are available to support backward compatibility for functions in Configurator Developer that operate over the Model structure hierarchy.
The table Compound Function lists the compound function that is available in CDL. The columns are Function and Description.
| Function | Description |
|---|---|
| OptionsOf | Takes BOM Option Class, Component, or Feature as an argument and returns its Options. |
It is possible that some arithmetic functions produce an error either because of the resulting size (larger than the largest positive or negative double) or an invalid input. Entering a meaningful rule violation message can be helpful when debugging errors.
For more information about violation messages, see the section on violation messages, Oracle Configurator Developer User's Guide.
Following are some examples of possible error messages.
Invalid Input Range Error
Consider a Numeric rule in which Acos(A-integer) contributes to a Total. When the input is out of the valid domain range (-1 to 1), Oracle Configurator returns the following error message.
There is a contradiction selecting A-Integer
To enhance the usability of this error based on the particular rule, you can specify the following violation message to appear after the system error.
Calculation of ACos(x) - x is not a valid value.
Intermediate Value Propagation Error
It is possible that propagation through some math functions results in an unexpected error because of an intermediate value propagated to the argument of the function. The following Model has a Feature with two counted Options (Option1 and Option2), a Resource (R) with no initial value (default is 0), and a Total (T) with no initial value (default is 0).
Numeric Rule 1: Contribute Option1 *-1 to R
Numeric Rule 2: Sqrt(R) contribute to T
If Option1 is 1, then R has a value of -1. Numeric rule 2 tried to calculate the Sqrt(-1) and Oracle Configurator returns the following error message.
There is a contradiction selecting 0ption1.
To enhance the usability of this error based on the particular rule, you can specify the following violation message to appear after the system error.
The result of an intermediate rule gives R an invalid value.
Calculated Input Value Out of Range Error
The following Model has a Boolean Feature (B1), a Feature with two counted Options (Option1 and Option2), a Resource (R) with no initial value (default is 0), and a Total (T) with no initial value (default is 0).
Numeric Rule 1: (Option1)*2000 contribute to T
Numeric Rule 2: Contribute CosH(T) * -1 to R
If Option1 is 1, then T has a value of 2000 and CosH(T) produces a result that is greater than the max of a double and Oracle Configurator returns the following error message.
There is a contradiction selecting 0ption1.
To enhance the usability of this error based on the particular rule, you can specify the following violation message to appear after the system error.
This rule uses the value calculated from Numeric Rule 1 - 0ption1 * 2000.
Calculated Value Not Within Valid Range Error
A Model has two integer Features (I1 and I2) with initial values of 0. Totals (T1 and T2) with no specified initial values. The Numeric rule ACos(I1-I2) contributes to T1. If I1 is 1 and I2 is 3, then I1-I2 is outside the valid range (-1 to 1) for ACos(x). Oracle Configurator returns the following error message.
There is a contradiction selecting I2.
To enhance the usability of this error based on the particular rule, you can specify the following violation message to appear after the system error.
The resulting value of I1 - I2 is outside the valid range of ACos(x).
Note: This behavior depends on the order in which the relations are propagated.
Operands are the rule participants upon which the actions of keywords and operators are executed. The following are kinds of operands:
See Notation Used in Presenting CDL Grammar for the syntax definition of operands.
References are identifiers that refer to Model objects by name (Model nodes or Model Properties). At runtime, the object or its value is used in the rule. A reference could be a Model node or a Property reference.
A Model object identifier is a token that refers by name to a particular object in the Model structure. At runtime it's the node or the value that is actually used in the rules they participate in depending on the context.
Model object identifiers have two different representations: quoted with the single quote ('...'), or not quoted. They do not have to be quoted if they refer to Model nodes with names that contain only letters or digits, but they must be quoted otherwise (for example, if the name contains a space, special character or is the same as a keyword.). The table Representations of Model Object Identifiers lists several representation of Model object identifiers, quoted and unquoted.
For example:
| Model Object Identifier | Refers to... |
|---|---|
| House | Model called House. |
| 'House' | Model called House. |
| 'Total Material' | Node called Total Material. Because the node name contains a space, it must be quoted. |
See References for details.
References to Model nodes can be made using simple identifiers that specify the name of the Model node. Model node references are context dependent. Since there may be nodes that have the same name within a Model, just using a Model identifier may be ambiguous depending on the context. (Model nodes created in Configurator Developer must be unique only within the same parent. In other words, nodes that are siblings in the Model structure cannot have the same name.)
For example, based on the House Model shown in Example House Model, the context of the node called Color is ambiguous because it could refer to the Feature in the House Model or to the Feature of the same name in the referenced Window Model.
Descendant Model nodes in the current Model context are always with higher priority than ancestor nodes. Thus Color in context Frame is not ambiguous (since Frame is a descendant node of House), but Color of the House is ambiguous. When it is not possible to uniquely refer to a Model node in the context of a rule, you must use compound identifiers. For details, see Compound Model Node References Showing Context.
Compound Model node references are sequences of Model node identifiers separated by the dot character (.). Compound references uniquely identify Model nodes in a particular context by presenting Model node paths. Compound references are necessary because Configurator Developer allows Model nodes to have identical names in the same Model structure as long as they are not siblings. In other words, Compound references are used for navigation in the Model structure. The most explicit path is the full path. A full path contains all levels of the hierarchy by node name, including Model, nested components, references, Option Classes, and Features.
In Full Path Model Node References, the first line shows the full path of Option Dark in the Feature Tint in the Component Glass in the referenced Model SideWindow2 in the parent Model House. The second line shows the full path of Color in Frame in FrontWindow1 in House.
Full Path Model Node References
... House.SideWindow2.Glass.Tint.Dark ... House.FrontWindow1.Frame.Color ...
You can omit any head of the path that does not disambiguate the reference. So to refer precisely and only to Color in the context of House, you must specify enough of the head of the path. The reference in Relative Path Model Node Reference unambiguously refers to Color in Frame in FrontWindow1 in the House Model.
Relative Path Model Node Reference
... FrontWindow1.Frame.Color
...
Identifiers that refer to System and User Properties of Model nodes must also be compound. When referring to User Properties, you must use the explicit method Property(). For example, in the context of Example House Model, House.FrontWindow1.Property("Position")refers to the User Property called Position. House.FrontWindow1.Position instead refers to a child Model node called Position.
When referring to System Properties, use the name of the System Property name directly. For example, FrontWindow1.MinInstances() refers to the MinInstances System Property.
The table Property References lists all methods available on Model node identifiers. Return Type indicates the data type of the value returned by the method cited in the Relationship column. Mutable, if Yes, means the value returned is affected by changes in the state of the Model at runtime including instantiation of nodes. The columns are Relationship, Applies to, Mutable, Return type, and Description.
| Relationship | Applies to | Mutable | Return type | Description |
|---|---|---|---|---|
| <identifier>.Name() | All model nodes | No | TEXT | Resolves to the model node name of the current identifier. |
| <identifier>.Description() | All model nodes | No | TEXT | Resolves to the model node description of the current identifier. |
| <identifier>.Options(), | Option Features, BOM Option Classes, BOM Models | Yes | NODE[] | Resolves to a collection of references to all child model nodes of the current identifier. |
| <identifier>.Property("<text literal>") | All model nodes | No | BOOLEAN, INTEGER, DECIMAL, or TEXT | Resolves to a reference to the named user-defined property of the current identifier. Return type depends on the type of the user-defined property. |
| <identifier>.MinInstances() <identifier>.MaxInstances() | Components and BOM models | Yes | INTEGER | Resolves to the dynamic min/max number of instances available at runtime. |
| <identifier>.InstanceName() | Components and BOM models | No | TEXT | Resolves to the instance name of the current identifier. |
| <identifier>.Selection() | Features and option classes that have Maximum Number of Selections = 1 | Yes | NODE | Resolves to the dynamic child model node of the current identifier that is selected at runtime. |
| <identifier>.State() | Boolean Features, Option Features, Options, and BOM nodes | Yes | BOOLEAN | Resolves to the dynamic state of the model node. |
| <identifier>.Value() | Features and BOM nodes | Yes | INTEGER, DECIMAL or TEXT | Resolves to the dynamic value of the model node. Return type depends on the model node type. |
| <identifier>.Quantity() | Options and BOM nodes | Yes | INTEGER or DECIMAL | Resolves to the dynamic quantity of the model node. Return type depends on the model node type. |
The Oracle Configurator parser does not allow the following property references on the left hand side of the rule when using CONTRIBUTE...TO statements:
<identifier>.Selection.State
<identifier>.Property("<text literal>")
Formal Parameter shows invalid use of property references used in CONTRIBUTE...TO statements.
Invalid Property References with CONTRIBUTE...TO Statements
CONTRIBUTE a TO b.Selection().State()
CONTRIBUTE a TO b.Property("RequiresGlossyFinish")
For details about using Model nodes and System Properties when defining rules, see the section on node types and System Properties, Oracle Configurator Developer User's Guide.
Formal parameters are local variables defined in rule iterators. They consist of the name of the identifier, prefixed with the ampersand character (&). Each parameter must be unique among the others. Since formal parameters are always prefixed there is no danger of ambiguity with model node references. Model nodes with the same name as a formal parameter (&win) must be in quotes when referred to in CDL ('&win').
In Formal Parameter, the parameter &var is used in the CONTRIBUTE statement. It is declared in the FOR ALL iterator, and it is used in the WHERE clause.
CONTRIBUTE &var.Property("NumProp") + 10 TO d
FOR ALL &var IN a.Options()
WHERE &var.Property("prop3") < 5;
Local variables are used exclusively for rule iterators (FOR ALL) and are implicitly declared a data type equivalent to the inferred type of the iterator collection. This allows the Oracle Configurator parser to catch data type errors rather than leaving it to the compiler.
Valid Local Variable of Inferred Data Type shows an acceptable use of a local variable of inferred type NODE.
Valid Local Variable of Inferred Data Type
...
CONSTRAIN &Color.Selection().property("dark") IMPLIES Frame.Glass.Tint.Dark
FOR ALL &Color in OptionsOf(Color);
...
Once the inferred type of the local variable is determined, the Oracle Configurator parser can validate its use in the context. For example, a local variable of type NODE can be combined with a Model object identifier to produce a compound reference to a Model node or Property.
The Oracle Configurator parser allows the reference shown in Valid Formal Parameter and Reference, but an error displays when you generate logic if &LocalVar evaluates to a node or a Property (not the name).
Valid Formal Parameter and Reference
... &NodeArg.Child(&LocalVar) ...
The Oracle Configurator parser does not allow the references shown in Formal Parameter and an Invalid Reference. In the first line, a formal parameter can appear only at the beginning of a Model object reference. In the second line, a Property must evaluate to Property value.
Formal Parameter and an Invalid Reference
... &NodeArg.&LocalVar &NodeArg.Property(&LocalVar) ...
CDL supports the use of literals of any of the primitive data types:
See Notation Used in Presenting CDL Grammar for the syntax definition of literals.
Numeric literals are simply presented as a sequence of digits as in Java. The table Types of Numeric Literals lists the type or numeric literals available in CDL. The columns are Numeric Literal and Description.
Boolean literals are presented by the keywords TRUE and FALSE.
Text literals are presented by a sequence of Unicode characters enclosed in double double-quotes ("..."). Comments and whitespace characters are not detected inside text literals. Literal concatenation is allowed using the plus (+) operator - this allows long text literals to be placed on multiple lines. The resulting terminal symbol is still returned as a single literal.
Text Literals
..."This is a text literal"... "This text is not a /*comment*/. "+ "All symbols are included in the literal" ...
... "This \"text\"\n is quoted and on two lines"...
Multiple-Line Text Literal
... "This is also a text literal "+ "that continues on this line "+ "and this. It forms one long line of text" ...
The table Escaped Characters Inside Double Quotes lists the escaped characters that can be used inside the double quotes, and the hexadecimal value, abbreviation, and a description of each.
| Escaped Character | Hexadecimal Value | Abbreviation | Description |
|---|---|---|---|
| \t | \u0009 | HT | horizontal tab |
| \n | \u000a | LF | linefeed |
| \f | \u000c | FF | form feed |
| \r | \u000d | CR | carriage return |
| \" | \u0022 | " | double quote |
| \\ | \u005c | \ | backslash |
Collection literals are not exactly literals in the token sense as they are described in the syntactical grammar. They consist of a sequence of tokens (identifiers or literals) separated by commas (",") and enclosed by braces ("{" and "}"), as shown in A Valid Collection of Integer Literals through Invalid Collection .
In the example Valid Collection of Integer Literals, Collection 2 shows an element of a collection being specified as another collection. Collections that contain other collections are flattened into a flat list of elements when the rule is compiled. In other words, the content of the inner collection is substituted into the outer collection.
Valid Collection of Integer Literals
Collection 1
...
{3, 25, 0, -34, 128}
...
Collection 2
...
{3, 25, {0, -34}, 128}
...
The example Valid Collection of Nodes shows several valid collections of Model nodes.
Collection 1
...
{A, B, OptionsOf(C)}
...
Collection 2
...
{A, B, C1, C2, C3}
...
Collection 3
...
{MyTotal, MyFeature}
...
Collection 4
...
{FrontWindow1, FrontWindow3, SideWindow2}
...
In the example Valid Collection of Nodes, Collection 2 is the same as Collection 1 with exploded children of C. And Collections 3 and 4 contain Model node names.
Only collections of homogenous data types are allowed in CDL. That means you cannot mix integer and text literals in a single collection. But you can mix them if the different literals can be implicitly converted to the same type. See Data Types for more information about implicit conversions. Validation of a homogeneous collection checks that all elements in the collection are valid for all uses of the collection.
As shown in the following examples, the inferred data type of the collection is the least common type of all elements:
In the example Valid Collections of Decimals, Collection 1 is a valid collection of decimal literals. Collection 2 is also a valid collection of decimals because MyTotal converts to a decimal.
Collection 1
...
{3, 25.0, 1e-9, -34}
...
Collection 2
...
{MyTotal, {1e-9, -34}}
...
The example Invalid Collection shows an invalid collection because there is no distinct data type that can be inferred.
...
{"aha", 25, 128, true}
...
Separators are characters that serve as syntactic filling between the keywords and the expressions. Their goal is to maintain the structure of the token stream by introducing boundaries between the tokens and by grouping the tokens through some syntactic criteria. See Notation Used in Presenting CDL Grammar for the syntax definition of separators.
The table Valid CDL Separators lists the separators that are valid in CDL. The columns are Separator and Description.
Both comments and the whitespace category of elements are not tokens and therefore ignored by the Oracle Configurator parser.
See Notation Used in Presenting CDL Grammar for the syntax definition of comments and whitespace.
You can add either single-line or multi-line comments to a rule written in CDL. Single-line comments are preceded by two hyphens ("- -") or a two slashes ("//") and end with the new line separator (such as a carriage return or line feed). A multi-line comment is preceded by a slash and an asterisk ("/*"). An asterisk followed by a slash ("*/") indicates the end of the comment.
CDL Comments shows single-line and multi-line comments.
-- This is a single-line comment // This is also a single-line comment /* This is a multi-line comment, spanning across lines */
Multiple Line Comments within a Statement Rule shows multiple comment lines within a Statement Rule.
Multiple Line Comments within a Statement Rule
/****************** * This constrains the color of the frame * to the tint of the glass. */ BLACK -- This comes from Frame.Color.Black IMPLIES Dark -- This comes from Glass.Tint.Dark
The constraint shown in Multiple Line Comments within a Statement Rule can also be written as follows without losing its syntax and semantics:
Black IMPLIES Dark
See Comment Symbols for more information.
Whitespace characters include the following:
Blank spaces (’ ’)
Tabs (’\t’)
New lines (’\n’)
Line feed (’\l’)
Carriage return (’\r’)
Form feed (’\f’)