AppLogic23 Web
AppLogic 2.3 Beta Documentation The latest production release is AppLogic 3.0.30Syntax Rules That Apply to All Descriptor Types
As ADL is based on UDL, all of its descriptor files share common syntax properties, as follows:Lexemes
Here are the smallest units of grammar used in the ADL language, defined as Perl-style regular expressions:| Reg expr | Sym | Use | Notes |
[A-Za-z_][A-Za-z0-9_]* | SIDENT | entity name, entity type | A simple identifier. This is the identifier sub-set that is acceptable to most text-based languages used, including shell command interpreters (bash, csh), Perl,C, Java, etc. Most user-defined names in the ADL language are of this type (exceptions are noted, where needed). |
[A-Za-z_$.-] [A-Za-z0-9_$.-]* | IDENT | entity name, attribute name | An identifier. Similar to a C identifier, but '-', '$' and '.' are also valid characters. |
[^,"'>=#\s]+ | STR | attribute value | A "bare" string. A string that is not quoted is allowed as a value for an attribute, if it does not contain any special characters. |
'[^']*' or "(\\["]!\\t! \\n!\\r![^"])*" | STR | attribute value | A quoted string, with two variants - single-quoted and double-quoted, interpreted in a manner similar to Perl - the single-quoted string recognizes no special meta-characters and can quote any printable characters except a single quote; the double-quoted string recognizes the \ meta-character and allows quoting of the double-quote itself and some non-printable characters as well. |
[\]\[{}:,='"] | punctuation | See the Punctuation Details section below. | |
=> | punctuation | Association separator | |
[ ]+ | whitespace | whitespace is a syntax separator, whenever two adjacent lexemes cannot be distinguished otherwise (e.g., two identifiers). In all other cases, whitespace between lexemes is simply ignored. | |
\n | separator | A newline or the EOF assertion. Multiple newlines are treated as one. | |
Punctuation Details
ADL is line-oriented, that is, it treats the newline character differently from other whitespace. Please note that in all the syntax descriptions below, the newlines are significant and the presence of a newline in a syntax example means that it is required. Here is the meaning of other punctuation characters in ADL: : | separates an entity definition from an in-line list of attributes for that entity |
, | separates attributes in an attribute list following an entity definition (in-line attributes) |
{} | block separators. These must appear alone on a line. A pair of braces encloses a set of attributes and/or sub-entities related to the entity after which they appear. Only one block is allowed per entity and only a single pair of braces should be used to enclose it, i.e., constructs like these below are invalid:input X input X |
[] | array block separators. A pair of square brackets following an entity heading identifies it as an "array" entity. Like the { } separators, these must appear alone on a line. Each line in the [ ] block is a comma-separated list of attributes for a single array element. |
\ | when found at the end of a line, this is a 'line continuation' character. The next line is treated as part of the current line. |
# | comment separator. All characters following #, up to the end of line are ignored (including the \ line continuation character). |
Descriptor Structure
Each descriptor file has the following overall structure: entity-type entity-name {
attributes-and-subentities }
Where:
entity-type is one of component, assembly or package and identifies the type of descriptor that is contained in the file.
entity-name is the name of the entity being described in this file (SIDENT).
attributes-and-subentities is an unordered set which contains any number of attributes and sub-entities. Each attribute is on a single line and has the form: 'name=value'., where name is an identifier (IDENT) and value is a string value (STR). Each sub-entity has one of the following forms:
name : attributes
typename :attributes name
{
attributes-and-subentities }
typename
{
attributes-and-subentities }
type and name are the type and the name of the sub-entity, respectively. attributes is a comma-separated list of name=value pairs. Note that attributes can also be specified in the
{ } block following the entity heading line. When attributes are specified on the same line as the entity definition (after the colon), binary attributes can be specified without a value (just the attribute name, meaning 'set to 1'), e.g.
volume boot: dev=/dev/hda1, ro
is the same as
volume boot: dev=/dev/hda1, ro=1
Each subentity type defines a namespace, and within that namespace only one subentity of a given name can exist. That applies to the sub-entities with no type at all (one can think of the subentities with no type as having the empty string as the type).
Specifying attributes both in-line and in the { } block is allowed, it should be avoided except in the cases where one particular attribute should stand out (e.g., the .class attribute in a subordinate component's specificaion); otherwise for simpler sub-entities with few attributes the inline syntax is preferred; for more complex entities that have many attributes and/or sub-entities, use the { } block.
 |
|
Copyright © CA 2005-2011. All Rights Reserved.