This appendix provides additional information about the Oracle Configurator parser’s expectations and requirements during rule validation.
This appendix covers the following topics:
As with any language, CDL requires a precise syntax and grammar to ensure that it can be interpreted by Oracle Configurator. The Oracle Configurator parser handles validation at the level of individual rules. A compiler uses the parser to validate the entire set of rules in a configuration model, and then translates them into executable code.
The Oracle Configurator parser analyzes the CDL input stream of a rule definition. The parser ignores whitespace and comments and only analyzes the tokens of the input stream to determine if the rule definition is valid.
The parser validates the grammar and structure of rule definition tokens according to the Extended Backus-Naur Form (EBNF). For more information, see Notation Used in Presenting CDL Grammar. The parser is part of the compiler. For details about the compiler, see The Compiler.
In Configurator Developer, clicking the following buttons in the Statement Rule Details page calls the Oracle Configurator parser:
Validate Rule Text
Apply
Apply and Create Another
Unless all of the following are true, the parser returns an error:
All tokens are known CDL elements
The token order is correct according to CDL syntax
Data types match within an expression
Model nodes specified in the rule exist in the Model structure, and can be unambiguously identified by the specified path.
Note that it is possible for the parser to successfully validate a rule, but an "ambiguous reference" error message then appears when generating Model logic. This is because Model structure changes can cause a reference to become ambiguous after the parser validates a rule. For more information, see Simple Model Node References.
Model names that are identical to a CDL keyword are in quotation marks
Node names containing spaces are in single quotation marks
Comment statements are properly delimited with a double hyphen, double slash, or /* and */
A variable (formal identifier) contains an ampersand (&) preceding the variable name
A variable name is declared only once in the same scope
A variable appears only once in a single statement (&NodeArg.&LocalVar)
The Oracle Configurator compiler parses all the rule definitions in a Model and then translates the rule set into executable code that can be interpreted by the runtime Oracle Configurator engine.
The compiler runs when you generate Model logic in Configurator Developer.
For more information, see the section on generating Model logic, Oracle Configurator Developer User's Guide.
For information about generating logic programmatically using CZ_modelOperations_pub.GENERATE_LOGIC and CZ_modelOperations_pub.REFRESH_JRAD_UI, see the Oracle Configurator Implementation Guide.
Unless the following are true, the compiler returns an error:
Text expressions evaluate to a static string (information that does not change at runtime)
The passed parameter resolves to a reference to an existing Model node or Property
User Properties must be static strings
For example, &A.Property("Hi") but not &A.Property(B.value)
Participants of LIKE and NOT LIKE evaluate to a static string
The input stream presented to the Oracle Configurator parser for lexical analysis is a sequence of Unicode characters. The input stream is processed through the following translations:
All Unicode escaped characters from the input stream are translated into raw Unicode characters. For information about the format, see Unicode Characters.
All input characters are translated via the lexical rules into lexemes. The lexemes are whitespace characters, comments, and tokens. Whitespace characters and comments are ignored.
If there are errors in the lexical translation of characters into tokens they will be raised as parser errors.
Successfully translated tokens are presented for syntactical analysis as a stream of terminal symbols. Tokens in the input stream can be one of the following types:
Keyword
Operator
Literal
Identifiers
Separator.
Additional details about each token type are provided in CDL Statements.
Unicode escaped characters are of the format \uxxxx where xxxx is the hexadecimal value representing the character in the Unicode character set. For example the Unicode escape of the character "?" is "\u003f".
When parsing identifiers that are references, the Oracle Configurator parser extracts the identity of each identifier (ps_node_id/model_ref_expl_id) and stores it with the intermediate representation of the identifier. This preserves the semantics of the rules regardless of name changes or modifications to the Model structure.
Since the model object identifiers are case insensitive, the Oracle Configurator parser must preserve the original format of the rule definition. If the Model structure or node names participating in the rule do not change, Configurator Developer displays the original text exactly as it was entered.
If the name of a rule participant changes, Configurator Developer automatically updates the displayed rule definition at the time of viewing or in the Model Report to prevent you from being misdirected to a different or no longer existing Model node.
Model structure changes or changes to a node can cause one or more of the references participating in a rule definition to become ambiguous. You must manually resolve ambiguities by inserting or removing identifiers from the reference, as needed.