Diagram Conventions

From BR Wiki
Revision as of 19:34, 5 August 2013 by Laura (talk | contribs) (Created page with "===Uppercase VS Lowercase Letters=== Throughout this reference material, uppercase letters are generally used to denote the names of commands, statements, functions and other ...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Uppercase VS Lowercase Letters

Throughout this reference material, uppercase letters are generally used to denote the names of commands, statements, functions and other specifications. Uppercase is also used with the names of most files or programs except where the file or program being referred to is exclusively used with the Unix or Linux operating system. Regardless of your operating system, Business Rules accepts both uppercase and lowercase letters as identical except when they are used in a literal string. It defaults to displaying all but literal strings in uppercase (see the BRConfig.sys STYLE specification to change this default).


Diagram Rules

Syntax diagrams show the optional and required parameters for statements, commands and specifications. The following LINPUT statement diagram will serve as an example for the set of rules, which applies to all Business Rules syntax diagrams

Read from left to right

The logic and order of the syntax always flows from left to right.

Uppercase parameters are exact keywords

Items in uppercase letters (LINPUT) are keywords and must be typed in either letter-for-letter as they appear or with an allowable abbreviation (see keyword abbreviations for a complete list).

Lowercase parameters must be replaced

Items in lowercase letters (string-var) are specifically defined in the Parameters section following each syntax diagram. When specified, these parameters must be replaced with a specification that fits the requirements of the definition. Descriptions of these parameters can be found in the Definitions and All Parameters sections.

Include special characters

Special characters, such as commas, colons and slashes (the colon in filenum:) must be included in the written statement.

Items on the main line are required

Items that appear on the main line of the diagram (string-var) must be included in the written statement. If you can follow the line of the diagram to the end without passing a parameter, it is optional.

Items above or below the line are optional

Items that appear above or below the main line of the diagram (error-cond line-ref) are optional.

Dotted line items with an arrow can be repeated

Items with a returning dotted line may be repeated. When multiple items are indicated, they must be separated with the punctuation mark (usually a comma or semi-colon).

Defaults are listed in brackets

Numbers that are enclosed in brackets (<1>) identify the default action or value, which is taken when nothing is specified for an optional parameter. These numbers correlate to the "Defaults" section below each diagram.

Insertable diagrams

Some of Business Rules commands and statements are so powerful that it is difficult to show all the available options in a single diagram. In cases such as this, a section of the diagram may be shown separately as an "insertable syntax". An example of this usage is the "helpstring" parameter that appears in several diagrams, including INPUT FIELDS. Another example is the "share spec" parameter (shown below). Insertable diagrams do not have start and end circles to prevent them from being confused with full syntax diagrams.

End of statement

The circle at the end of the diagram identifies the end of the statement.

For more details, see the Syntax description.