Syntactic and semantic analysis

The problems of naming collision and resolving dependencies between different entities have been addressed by several techniques employed by compilers while transforming the source code written in a programming language into a binary form. In the case of Patterns it was necessary to address a similar problem due to its inner nature of transforming a file storing a set of configuration into a set of values interpretable by the CMS.
This is especially important while re-using patterns exported automatically as the ones described in the previous section, since the state of a website might not fullfill the requirements to make use of the configuration of a pattern exported by another website.

The new version of Patterns allows the components to implement two separated layers of syntactic and semantic validation, providing a very valuable feedback to the user that is going to run a pattern in case it is necessary to solve any possible conflicts.

It was necessary to analyze and classify all these conflicts in order to establish a set of principles that ensure a pattern is syntactically and/or semantically valid. As a rule of thumb we will consider syntactic errors/warnings the ones related to wrong grammar statements, and semantic warnings the ones that would provoke execution errors related to the meaning of the pattern itself.
The relationship is inclusive: a pattern semantically valid will always be syntactically valid, but not the other way around. The next subsection provides a set of examples of the possible errors and warnings we have currently discovered and classified.

Syntactic warnings

They refer to wrong grammar statements that will not provoke any execution error. Examples of syntactic warnings are attributes that will not be used by that tag, or grammar mistakes in optional attributes.

The following Pattern shows an example of a syntactic warning: the fake attribute “fakeatt” in this pattern will not be interpreted by the component, but it will not provoke any collateral consequences:

Syntactic errors

They refer to wrong grammar statements that will provoke an execution error. Examples of syntactic errors are misspellings in required attributes or actions that do not apply on that component.

The following Pattern shows an example of a syntactic error: the mandatory attribute “name” has been misspelled as “namenn” and this will provoke an error during the execution:

Semantic warnings

They refer to the meaning of the pattern itself, and they might provoke execution errors if they are not solved. Currently we have identified the following types:

1. Already defined element: This refers to the problem of creating an element that it is already present in the system and whose scope is on a inner-component-tag basis.
   E.g., while creating a menu that it is already stored in the system.
2. Element undefined: This refers to the problem of trying to perform changes in an element that is not present in the system yet and whose scope is on a inner-component-tag basis.
   E.g., while modifying a system variable that does not exist in the system.
3. Unmet dependency: This refers to the problem of creating an element that depends on the creation of another element whose creation belongs to another component (or another tag of the same component). The scope of the error is therefore in a external-component or external-tag basis.
   E.g., while trying to define a shorcut set (shortcut component) for an user that does not exist yet (user component), or define a permission (user component, tag permission) for a role that has not been defined yet (user component, tag role).
4. Remaining dependencies: This refers to the problem of deleting a part of the configuration that affects elements defined by other components.
   E.g., Deleting a content type leaves the nodes of that type as “undefined”.
5. Not unique alias: This refers to the problem of modifying or creating an element that belongs to a set that identifies uniquely certain entity, being a similar constraint as the Unique constraint in Databases.
   E.g., Creating a new block whose delta and info values (alternative way to identify it besides the Primary Key element) already exist in the system.
6. Inconsistent operation: This refers to perform an action that, although syntactically valid, Drupal core does not support.
   E.g., Delete a block that has been not defined through the Block component.

The following Pattern shows an example of a semantic warning: Although the pattern is syntactically valid, since the roles already exist, the system will raise two semantic warnings of type “Already defined element” while performing the validation: