AdvADLSyntaxRulesGeneral < AppLogic1

Sep 7 - AppLogic 2.1 has been officially released! See the release notes for details.

Syntax 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 { { # double brace - illegal protocol=http } }` `input X { } { # second block for same entity - illegal protocol=http }`
`[]`	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.

-- VladM - 25 May 2006

Topic AdvADLSyntaxRulesGeneral . { Edit | WYSIWYG | Attach | Backlinks: Web All webs | Printable | History: %REVISIONS% More }

	Wiki > AppLogic1 > AdvADLSyntaxRulesGeneral	Wiki webs: Main \| TWiki \| Sandbox
	AppLogic1 . { Changes \| Index \| Search \| Go }	Hello TWiki::User=HASH(0x 8b 4def 0)? !