ch-express.tex

% !TEX root = thesis.tex
\chapter{Expressing CSS Code Conventions}
\label{sec:expressing}

This chapter introduces CssCoco -- a domain--specific language capable of expressing CSS conventions. First, the convention corpus is analyzed and the meaning of conventions is made explicit. Second, the abstract and concrete syntax of CssCoco are defined. Third, an implementation of the language interpreter is presented. Finally, the solution is validated using ontological analysis.

\section{Analysis of conventions corpus}

Code conventions is an umbrella term that comprises rules for whitespacing, comments, indentation,
naming, syntax, code patterns, programming style, file organization, etc. To gain an overview of the
type of conventions used in the CSS domain, all conventions in the corpus are organized in groups
depending on the type of constraints they impose. The following three categories were defined
(sublists provide examples of conventions that fall in each category):

\begin{description}
  \item[Layout] category contains rules that constrain the overall layout of the code. It includes conventions related to whitespace, indentation and comments. Examples include:
  \begin{itemize}
  \item Use four tabs for indentation.
  \item Put one blank line between rulesets.
  \item Disallow spaces at the end of the line.
  \end{itemize}
  \item[Syntax Preference] category comprises conventions that express preference of a particular syntax. Note that rules in this category do not aim at ensuring CSS validity, but choose between syntactic alternatives. For example, both single and double quote strings are valid in CSS and a convention may narrow down the choice of the developer to single quotes. Examples include:
  \begin{itemize}
  \item Use lowercase for id and class names.
  \item Require a semicolon at the end of the last declaration.
  \item Use strings with single quotes.
  \end{itemize}
  \item[Programming Style] category consists of conventions that put constraints on how CSS constructs are used to achieve a certain goal. They specify preferred code patterns or anti-patterns. Conventions in this group are used mainly to improve maintenance and performance, or to avoid issues in a particular implementation. Examples are:
  \begin{itemize}
  \item Do not use the universal selector.
  \item Avoid using !important.
  \item A vendor-prefixed property must be followed by a standard property.
  \end{itemize}
\end{description}

Conventions in each of the groups were analyzed and their violations were made
explicit. While the violations of most of the conventions are obvious, some of
them require knowledge about the grammar of CSS. For example, conventions such
as \textit{Avoid id selectors} directly describe their violations --- id
selectors. That said, the convention \textit{Use single quotes in URLs} has
two violations that are valid CSS code: URLs with double quotes and URL
without quotes.

After the violations of each convention were made explicit, the specific actions needed to detect
these violations were determined. Currently, the detection of violations is performed by developers
manually or with the partial help of tools. To perform such checks, developers need to understand
different concepts, e.g. the concept of a rule, HTML element, ID, etc. and perform certain actions,
such as find a structure, evaluate a constraint, etc. The analysis tries to grasp the specific
concepts and actions used to find violations. To illustrate the process, the analysis of one convention is included. Analysis of all conventions in the corpus is available at the CssCoco GitHub repository
\footnote{\url{https://github.com/boryanagoncharenko/CssCoco/blob/master/analysis.md}}.

\bigskip
\begin{boxedminipage}{.95\textwidth}
\begin{description}
\item\textbf{Convention:} Disallow empty rules.
\item\textbf{Author:} \href{https://github.com/CSSLint/csslint/wiki/Disallow-empty-rules}{CSS lint}
\item\textbf{Violations:} Presence of rulesets that do not contain declarations. In case at least one declaration is present, the ruleset does not violate the convention. Examples include:

\begin{lstlisting}[style=mono,language=Java]
.myclass { }                 /* violation */
.myclass { /* Comment */ }   /* violation */
.myclass { color: green; }   /* no violation */
\end{lstlisting}

\item\textbf{Actions:} Recognize rulesets and declarations. Determine whether a ruleset does not contain any declarations.
\end{description}
\end{boxedminipage}
\bigskip

The convention aims at getting rid of one type of refactoring leftovers ---
rulesets without declarations. Removing empty rulesets reduces the total size of CSS that
needs to be processed by the browser. One possible approach for discovering violations of the
convention at hand is to search the stylesheet for rulesets and then check whether each ruleset
contains a declaration. To perform this search successfully, developers need to understand the
concept of a ruleset and a declaration, i.e. they need to be able to recognize these two CSS
structures. Further, developers need to determine relations between structures, particularly,
whether a ruleset contains a declaration.

After all conventions were analyzed, the specific actions and concepts were
used to extract requirements and draw conclusions about the needed
functionality. First, every convention can be represented as a combination of
constraints, regardless of the way it is expressed. There are two major
constructs used to convey conventions in natural language: forbid and require.
Conventions that forbid describe directly their violations. For example, the
convention \textit{Disallow @import} specifies that import statements are
violations. Conventions that use the latter construct describe a pattern and
once the pattern is found, a constraint is evaluated. In case the constraint
is not met, a violation is discovered. For example, the convention
\textit{Class names should be lowercase} requires finding class nodes and then
checking whether they are lowercase.

As the three categories of conventions imply, conventions can reference nodes
from the abstract syntax tree, concrete syntax tree and parse tree~\cite{zaytsev2014parsing} of
CSS. For example, the convention \textit{A rule must
not contain width and padding declarations} accesses concepts that are present
in the abstract syntax tree. Similarly, the rule \textit{Put a semicolon at
the end of the last declaration} refers to nodes that are omitted by the
abstract syntax tree and are present in the concrete syntax tree. All
whitespacing and indentation conventions target nodes that are relevant only
to the parse tree of CSS.

Usually, the patterns described in conventions target one of all described
nodes. For example, when the pattern refers to rulesets in media queries, the
target node is the ruleset and the media query is part of the context.
Similarly, when a pattern describes a ruleset that contains a float
declaration, the target node is the ruleset and the float declaration is only
a context constraint. Certain conventions can have more than one target nodes,
e.g. when two declarations in a ruleset need to be compared.

Conventions refer to nodes using their type or function in the CSS program.
For example, in the snippet \texttt{[class=``test'']} the node test can be
selected 1) because it is of type string and 2) because it is an attribute
value. Similarly, a node with value \texttt{\#ffffff} may be selected because
it is a hexadecimal value or because it represents a color.

Conventions may use CSS-specific knowledge. For example, the rule \textit{Use
lowercase for properties; vendor-prefixed properties are exception} requires
differentiating between standard and vendor-specific properties. While in this
case the two types of properties can be easily distinguished, some conventions
require information that cannot be obtained using the CSS code. Consider the
convention \textit{Order vendor-prefixed values by their version; newer
versions of vendor values should appear after old ones}. To detect violations
for this convention the release dates of the properties need to be available
for comparison.

Conventions rarely target a single node. Typically, they refer to a number of
nodes organized in a pattern. For example, the convention \textit{A ruleset
must not contain display and float declarations} requires searching for two
specific declaration that appear under the same parent node. The nodes in the
pattern do not have to be immediate relatives. In fact, they can be scattered
across the tree. For example, the rule \textit{Do not use more than 5
@font-face declarations} requires searching for specific nodes that appear
anywhere in the tree.

\section{CssCoco DSL}

\subsection{Syntax overview}

To express the conventions in the corpus, the domain-specific language CssCoco
is proposed. It is a declarative language that has two main constructs:
conventions and contexts. Conventions express the specific rules that have to
be enforced on the code and contexts describe the CSS nodes that need to be
ignored while searching for violations.

The language constructs that define conventions try to resemble the way
conventions are expressed in natural language. There is a construct that describes
directly what is disallowed. For example, the convention \textit{Do not use
import statements} is expressed in the following way:

\begin{sourcecode}
\begin{lstlisting}[style=mono,language=Java]
forbid import
message 'Do not use import statements.'
\end{lstlisting}
\end{sourcecode}

The keyword \textit{forbid} is followed by a description of the node that is
disallowed. In the current convention, we only need to state its type ---
import. Each convention requires a message clause. The string after the
\textit{message} keyword will be displayed to the user when a violation is
found.

As the domain analysis indicates, conventions are often expressed as a pattern that, if found, needs to
meet given constraints. In CssCoco syntax such conventions are defined using the \texttt{find ...
require ...} construct. For example, the convention \textit{All class names should be lowercase} is
described as follows:

\begin{sourcecode}
\begin{lstlisting}[style=mono,language=Java]
find c=class
require c.name match lowercase
message 'All class names should be lowercase'
\end{lstlisting}
\end{sourcecode}

The find clause in the above rule specifies the pattern that needs to be found and the require
clause states the constraint that should be applied to the discovered nodes. Note that to refer to a
matched node in the require clause, the node should be assigned an identifier (\texttt{c} in the
above example).

Conventions can put more constraints on a node description in the pattern. For example, the
convention \textit{Use a leading zero for decimal values} requires finding all nodes of type number
that have a numeric value in the interval [-1, 1]. Such constraints are put in curly brackets
immediately after the type of the node.

\begin{sourcecode}
\begin{lstlisting}[style=mono,language=Java]
find n=number{num-value < 1 and num-value > -1}
require n.string match '^0.*'
message 'Use a leading zero for decimal values'
\end{lstlisting}
\end{sourcecode}

Conventions can describe patterns that consist of more than one node. For example, the rule
\textit{Use single quotes in charsets} can be expressed in the following way:

\begin{sourcecode}
\begin{lstlisting}[style=mono,language=Java]
find s=string in charset
require s.has-single-quotes
message 'Use single quotes in charsets'
\end{lstlisting}
\end{sourcecode}

The pattern contains the description of two nodes: first, a node that is of type string and a node
of type charset. The \texttt{in} keyword in the pattern description indicates that the string node
is nested in the charset node. In this way, the pattern will match only the strings that appear in a
charset.

In CssCoco, conventions are grouped in contexts that specify what nodes should be ignored when
searching for patterns. For example, often when rules refer to newlines they completely disregard
indentation. The convention \textit{Every declaration must be on a new line} requires a newline to
be present immediately before the declaration. However, when declarations are indented their
immediate previous sibling is an indentation node. To handle such cases, the language uses contexts
that explicitly describe the ignored nodes.

\begin{sourcecode}
\begin{lstlisting}[style=mono,language=Java]
Whitespace
ignore indent 
{
    find d=declaration
    require newline before d
    message 'Put every declaration on a new line'
}
\end{lstlisting}
\end{sourcecode}

Contexts have a user-defined name and an optional ignore clause. The \texttt{ignore} keyword is
followed by a description of the nodes that need to disregarded.

\subsection{Abstract syntax}

This section describes the abstract syntax of the designed domain-specific language. An overview of
the abstract syntax is presented in \autoref{fig:astgeneral}, followed by detailed views of each
of the subclasses.

\begin{figure}[h]
  \centering
  \caption{Abstract Syntax Overview}
  \label{fig:astgeneral}
  \includegraphics[width=\textwidth]{general}
\end{figure}


\begin{description}

\item\textbf{ConventionSet} represents a style guide. It comprises a number of conventions that form coherent guidelines. Attribute \texttt{contexts} is a list of Contexts that contains contexts.

\item\textbf{Context} represents a group of conventions that belong to the same semantic group (e.g. whitespacing, syntax preference, programming style). Attribute \texttt{conventions} is a list of Conventions that contains conventions. Attribute \texttt{ignored\_patterns} is a list of Patterns that are ignored while searching for the target pattern. For example, while searching for violations of semantic conventions, the whitespacing and indentation nodes are ignored.

\item\textbf{Convention} represents a rule that enforces specific constraints. Attribute \texttt{pattern} is the pattern that the convention targets. Attribute \texttt{description} is the description of the convention in natural text. This description is displayed to the user when a violation of the convention is discovered.

\item\textbf{PatternDescriptor} represents a description of a node or a combination of related nodes that a given convention constraints. Attribute \texttt{root} is the top node described in the pattern. Attribute \texttt{nodes} is a collection of all nodes described by the pattern. Attribute \texttt{relations} is a collection of relationships between the nodes used in the pattern.

\item\textbf{NodeRelation} represents a relation between two Nodes. Attribute \texttt{target\_node}
designates a description of the Node targeted by the relation.

\item\textbf{NodeDescriptor} is an abstract class that contains a description of a Css Node. Attribute
\texttt{constraint} is an expression that designates the constraints applied to the node.

\item\textbf{Node} represents a description of a node used in a PatternDescriptor. Attribute
\texttt{constraint} is an expression that designates constraints applied to the node.
Attribute \texttt{identifier} is a given string that can be used as a reference to the matched node.

\item\textbf{WhitespaceNode} represents a description of a whitespace node that references space,
newline, indentation symbols. Attribute \texttt{constraint} is an expression that designates
constraints applied to the node. Attribute \texttt{repeater} is an optional constraint that specifies
the number of times a whitespace node can appear consecutively. Repeaters are useful to express
conventions that do not specify exact quantities of whitespace symbols. For example, the convention
``put at least one blank line between rules'' sets a lower limit of the number of blank lines, but
not an upper limit.


\end{description}


\begin{figure}[h]
  \centering
  \caption{Abstract Syntax Expressions}
  \label{fig:expressions}
  \includegraphics[width=\textwidth]{expr}
\end{figure}

A detailed view of the expressions in the abstract syntax of CssCoco is presented in \autoref{fig:expressions}. Following is a description of the subclasses of Expression:

\begin{description}

\item\textbf{LiteralExpr} represents an expression containing a literal value. Attribute \texttt{value} is the value of the literal expression.

\item\textbf{VariableExpr} represents a reference to a matched node. Attribute \texttt{name} is the identifier used to reference the node.

\item\textbf{UnaryExpr} represents expressions with a single operand. Attribute \texttt{operand} is operand of the expression.

\item\textbf{NotExpr} represents negation expression.

\item\textbf{UnaryMinusExpr} represents unary minus expression.

\item\textbf{UnaryPlusExpr} represents unary plus expression.

\item\textbf{BinaryExpr} represents expressions with two operands. Attributes \texttt{left} and \texttt{right} represent the first and second operands, respectively.

\item\textbf{OrExpr} represents disjunction expression.

\item\textbf{AndExpr} represents conjunction expression.

\item\textbf{ComparisonExpr} represents expression that compares two operands.

\item\textbf{IsExpr} represents expression that checks whether the first operand is of the given type, specified by the second operand.

\item\textbf{InExpr} represents expression that checks whether the first operand is present in a list of values, specified by the second operand.

\item\textbf{MatchExpr} represents expression that checks whether the first operand matches a regular expression, specified by the second operand.

\item\textbf{CallExpr} represents expression that invokes a API property or method of the operand. Attribute \texttt{operand} is the operand of the expression. Attribute \texttt{value} is the name of the API property or method that is invoked.

\item\textbf{NodeQueryExpr} represents expression that queries node context. Attribute \texttt{operand} is the node used as a reference point for the query.

\end{description}

\begin{figure}[h]
  \centering
  \caption{Abstract Syntax Literal Expressions}
  \label{fig:literal}
  \includegraphics[width=0.9\textwidth]{literal}
\end{figure}

\autoref{fig:literal} presents a detailed view of the literal expressions used in the abstract syntax of CssCoco. Following is a listing of the classes. 

\begin{description}

\item\textbf{IntegerExpr} represents expression containing an integer value.

\item\textbf{DecimalExpr} represents expression containing a decimal value.

\item\textbf{StringExpr} represents expression containing a string value.

\item\textbf{BooleanExpr} represents expression containing a boolean value.

\item\textbf{NodeTypeExpr} represents expression containing a string value that describes a node type.

\item\textbf{ListExpr} represents expression containing a list value. The elements of the list are of type LiteralExpr.

\end{description}

\begin{figure}[h]
  \centering
  \caption{Abstract Syntax Literal Expressions}
  \label{fig:call}
  \includegraphics[width=0.2\textwidth]{call}
\end{figure}

\autoref{fig:call} presents a detailed view of the call expressions used in the abstract syntax of CssCoco. Following is a listing of the classes. 

\begin{description}

\item\textbf{PropertyExpr} represents an expression that returns the value of a property of the operand node. Attribute \texttt{operand} represents the node targeted by the expression. Attribute \texttt{value} holds the name of the property that is accessed.

\item\textbf{MethodExpr} represents an expression that invokes a method of the operand node. Attribute \texttt{argument} represents the argument passed to the invoked method.

\end{description}

\begin{figure}[h]
  \centering
  \caption{Abstract Syntax Node Query Expressions}
  \label{fig:nodequery}
  \includegraphics[width=0.9\textwidth]{nodequery}
\end{figure}

\autoref{fig:nodequery} presents an overview of the Node Query Expressions. The following listing describes the subclasses in details:

\begin{description}

\item\textbf{NextSiblingExpr} represents expression that returns the following sibling of the operand node.

\item\textbf{PreviousSiblingExpr} represents expression that returns the previous sibling of the operand node.

\item\textbf{NodeQueryWithArgExpr} represents expression that queries node context and uses additional constraints for the query. Attribute \texttt{argument} represents the additional constraints used by the query.

\item\textbf{ContainsExpr} represents an expression that checks whether the operand node contains a node that matches given constraints.

\item\textbf{ContainsAllExpr} represents an expression that checks whether the operand node contains nodes that match given constraints.

\item\textbf{CountExpr} represents an expression that counts the number of ancestor nodes of the operand that match a given constraint.

\item\textbf{BeforeExpr} represents an expression that checks whether a given pattern of nodes appears before the operand node.

\item\textbf{AfterExpr} represents an expression that checks whether a given pattern of nodes appears after the operand node.

\item\textbf{BetweenExpr} represents an expression that checks whether a given pattern of nodes appears between the two operand nodes.

\end{description}

\subsection{Concrete syntax}

This section contains the concrete syntax of the designed DSL. Below are presented the grammar rules accompanied by the mapping to the abstract syntax of the language.


\begin{description}

\item\textbf{stylesheet} represents a style guide.

Abstract Syntax Mapping: ast.ConventionSet.

\begin{snippet}
\begin{verbatim}
stylesheet : context* ;
\end{verbatim}
\end{snippet}

\item\textbf{context} represents a group of logically related conventions. A single style guide can comprise a number of conventions that enforce various constraints, e.g. whitespacing, syntax preference, program style. Contexts group conventions that ignore the same nodes while searching for their violations.  

Abstract Syntax Mapping: ast.Context.

\begin{snippet}
\begin{verbatim}
context : Identifier ignore_clause? '{' convention* '}' ;
ignore_clause : 'ignore' (node_descriptor)+ (',' (node_descriptor)+)* ;
\end{verbatim}
\end{snippet}

\item\textbf{convention} represents a single rule in the style guide. Conventions are typically expressed by directly stating what is disallowed or describing a condition that if met, requires additional constraints. The former way of expressing conventions is represented by the \texttt{forbid} conventions. The latter approach uses the structure \texttt{find ... require ...}. To break down complex disallowing conventions, the structure \texttt{find ... forbid ...} has been introduced. This aims at improving readability of conventions. Additionally, conventions have a where clause which applies constraints for matching nodes. It is used to expression matching constraints that span over multiple nodes and therefore cannot be present in the node descriptors.

Abstract Syntax Mapping: ast.Convention.

\begin{snippet}
\begin{verbatim}
convention : 'forbid' pattern ('where' logic_expr)? 'message' String
           | 'find' pattern ('where' logic_expr)? ('require'|'forbid') logic_expr 'message' String
           ;
\end{verbatim}
\end{snippet}

\item\textbf{pattern} represents a pattern of nodes and their relations. For example, it can describe a horizontal sequence of sibling nodes, a vertical pattern of nested nodes, or pairs of elements with a common parent. 

Abstract Syntax Mapping: ast.PatternDescriptor.

\begin{snippet}
\begin{verbatim}
pattern : node_declaration (('in'|'next-to') node_declaration)*
        | fork ('in' node_declaration)*
        ;
fork : '(' node_declaration (',' node_declaration)+ ')' ;
node_declaration : (Identifier '=')? semantic_node ;
\end{verbatim}
\end{snippet}

\item\textbf{node\_descriptor} represents a description of a node. It specifies the type of the node and its additional constraints. 

Abstract Syntax Mapping: ast.NodeDescriptor.

\begin{snippet}
\begin{verbatim}
node_descriptor : 'unique'? node_type ('{' (logic_expr|repeater) '}')? ;
repeater : Integer ',' Integer? | (',')? Integer ;
\end{verbatim}
\end{snippet}


\item\textbf{logic\_expr} represents expressions that perform logic operations and glue arithmetic and type expressions. 

Abstract Syntax Mapping: ast.NotExpr, ast.AndExpr, ast.OrExpr and all arithmetic\_expression and type\_expression mappings.

\begin{snippet}
\begin{verbatim}
logic_expr : '(' logic_expr ')'
           | 'not' logic_expr
           | logic_expr 'and' logic_expr
           | logic_expr 'or' logic_expr
           | type_expr
           | arithmetic_expr
           ;
\end{verbatim}
\end{snippet}

\item\textbf{type\_expr} represents expressions that ensure node type and perform node queries on nodes. They are located in a separate parser rule because they interpret Identifiers as node type expressions instead of a API calls. 

Abstract Syntax Mapping: ast.IsExpr, ast.BeforeExpr, ast.AfterExpr, ast.BetweenExpr.

\begin{snippet}
\begin{verbatim}
type_expr : arithmetic_expr operator='is' Identifier
          | node_descriptor+ ('before' | 'after') type_operand
          | node_descriptor+ 'between' type_operand 'and' type_operand
          ;
type_operand : Identifier | semantic_node ;
\end{verbatim}
\end{snippet}

\item\textbf{arithmetic\_expr} represents arithmetic, comparison, set membership and regex expressions. These are located in a separate parser rule because they interpret identifiers as API calls instead of node type expressions.

Abstract Syntax Mapping: ast.UnaryMinus, ast.UnaryPlus, ast.LessThan, ast.LessThanOrEq, ast.GreaterThan, ast.GreaterThanOrEq, ast.Equal, ast.NotEqual, ast.InExpr, ast.MatchExpr, ast.LiteralExpr.

\begin{snippet}
\begin{verbatim}
arithmetic_expr : ('-'|'+') arithmetic_expr
                | arithmetic_expr ('<'|'>'|'<='|'>='|'=='|'!=') arithmetic_expr
                | arithmetic_expr ('in'|'not in'|'match'|'not match') arithmetic_expr
                | call_expression
                | element
                ;
element : Boolean | Decimal | Integer | String | list_ ;
\end{verbatim}
\end{snippet}

\item\textbf{call\_expression} represents an API call expression and also node query expression.

Abstract Syntax Mapping: ast.CallExpr and ast.NodeQueryExpr.

\begin{snippet}
\begin{verbatim}
call_expression : call_expression '.' call_expression
                | Identifier ('(' (element | semantic_node ) ')')? 
                ;
\end{verbatim}
\end{snippet}

\item\textbf{Boolean:} represents Boolean literal expression. 

Abstract Syntax Mapping: ast.BooleanExpr.

\begin{snippet}
\begin{verbatim}
Boolean : 'true' | 'True' | 'false' | 'False' ;
\end{verbatim}
\end{snippet}

\item\textbf{String:} represents String literal expression.

Abstract Syntax Mapping: ast.StringExpr.

\begin{snippet}
\begin{verbatim}
String : "'" (EscapeSequence | ~['])*? "'" ;
EscapeSequence : "\\" "'" ;
\end{verbatim}
\end{snippet}

\item\textbf{Integer:} represents Integer literal expression. 

Abstract Syntax Mapping: ast.IntegerExpr.

\begin{snippet}
\begin{verbatim}
Integer : (ZeroDigit | NonZeroDigit Digit*) ;
Digit : ZeroDigit | NonZeroDigit ;
NonZeroDigit : [1-9] ;
ZeroDigit : [0] ;
\end{verbatim}
\end{snippet}

\item\textbf{Decimal:} represents Decimal literal expression. 

Abstract Syntax Mapping: ast.DecimalExpr.

\begin{snippet}
\begin{verbatim}
Decimal : ( NonZeroDigit Digit* | ZeroDigit? ) '.' Digit+ ;
Digit : ZeroDigit | NonZeroDigit ;
NonZeroDigit : [1-9] ;
ZeroDigit : [0] ;
\end{verbatim}
\end{snippet}

\item\textbf{list} and \textbf{list\_element} represent the List literal expression. 

Abstract Syntax Mapping: ast.ListExpr.

\begin{snippet}
\begin{verbatim}
list_ : '[' list_element (',' list_element)* ']' ;
list_element : Integer | Decimal | String | semantic_node ;
Letter : [a-zA-Z] ;
Identifier : (Letter)(Letter|Digit|'_'|'-')* ;
\end{verbatim}
\end{snippet}

\item\textbf{type\_expression} represents the NodeType literal expression.

Abstract Syntax Mapping: ast.NodeType.

\begin{snippet}
\begin{verbatim}
node_type : '(' node_type ')'
          | 'not' node_type
          | node_type 'and' node_type
          | node_type 'or' node_type
          | Identifier
          ;
\end{verbatim}
\end{snippet}

\end{description}

\subsection{Proof of Concept}

To study the feasibility of the designed language, a proof of concept was
developed. The implemented solution consists of two parts: a standalone
Python package and a plug-in for Sublime Text editor.

The first part of the designed solution comprises the CssCoco
interpreter. The implementation is done in Python and currently contains 13
000 lines of code. The source code is available at CssCoco GitHub repository
\footnote{\url{https://github.com/boryanagoncharenko/CssCoco}}. The solution was also
added to the Python Package Index (Pypi) repository
\footnote{\url{https://pypi.python.org/pypi?:action=display&name=csscoco}}
and for less than a month it has accumulated over 5000 downloads. The package offers a \texttt{csscoco} command that takes as
arguments a .css and a .coco files and returns a list of the discovered violations.

The current implementation of the CssCoco interpreter is available only for
Python 3.4. Additionally, the proof of concept requires nodejs. This
dependency is added because the only existing CSS parser that produces CSS
parse trees with the required level of details is implemented in nodejs.

The second part of the proof of concept brings the functionality implemented
in the Python package to Sublime Text editor. The plug-in uses the
\texttt{csscoco} command to find violations in CSS files that are being edited
in the text editor. Currently, the plug-in is implemented for Sublime Text 3.
The source code of the solution is publicly available at a separate GitHub repository
\footnote{\url{https://github.com/boryanagoncharenko/Sublime-CssCoco}}.

The plug-in offers a command that finds and visualizes violations. Similarly to
other linter tools, rows that contain violations are marked with a color
border and a gist appears at the side bar. When the cursor is positioned on a
line that contains a violation, the error message is displayed in the status
bar. For example, on \autoref{sublime} the cursor is placed on line 26 and the
status bar indicates that there should be one space between the colon and the
value of the declaration.

\begin{figure}[h]
  \centering
  \caption{
    \label{sublime}
    CssCoco Sublime Text Plug-in}
  \includegraphics[width=0.7\textwidth]{sublime}
\end{figure}

The proof of concept leaves some of the features of the language not implemented. Specifically, it does not include the following:

\begin{itemize}

\item Unique construct. A small portion of the conventions require the unique construct. The feature is not included in the current version and is left for future implementation.

\item Ordering rules. To check for violations of conventions that specify ordering, requires efficient implementation especially for large CSS files. The feature is currently not supported because of time constraints. 

\item Indentation rules. Conventions that refer to indentation specify relative indentation. For example, when a convention states that the contents of a ruleset should be indented, this implies that they should be indented once compared to the beginning of the ruleset. Detecting violations of such conventions is laborious and is left for future implementation.

\item Dictionary. A number of the conventions require usage of a dictionary. The feature is not included in the current version and is left for future implementation.

\end{itemize}

\section{Validation}

The method chosen for validating the designed domain-specific language is
ontological analysis, since it is a widely accepted way for evaluating
software notations
~\cite{opdahl2002ontological,green2000integrated,moody2009physics,parsons1997using,weber1996analytical}.
The particular approach used for conducting ontological analysis consists of
several steps. First, a domain-specific ontology is designed. Second, the
ontology is used as a reference point for the interpretation and
representation mappings. Third, emerged anomalies are analyzed and conclusion
about the quality of the notation is made.

\subsection{Ontology design}

The first stage of validation requires designing a domain-specific ontology. The domain of the
developed ontology is limited to detecting violations of CSS code conventions. In other words, the
designed ontology tries to capture only the concepts that exist when an agent searches a CSS stylesheet
for violations of given set of code conventions.

The designed domain-specific ontology is based on the BWW top-level
ontology~\cite{wand1990ontological}, i.e. it uses the high-level categories of
the BWW ontology to describe the objects, concepts and entities in the
specific domain. The rationale behind the decision to use the BWW ontology is that
it is the leading ontology used for ontological
analysis~\cite{moody2009physics}. The main ontological constructs used in the
BWW ontology are listed in section 2.1.

The designed ontology is presented using several approaches. As recommended by
Wand and Weber, the ontology is described using a dictionary comprising
definitions of entities in natural text and, second, using Backus-Naur Form
(BNF) notation~\cite{wand1995deep,rosemann2002developing}. Additionally, a
system diagram is included to provide a better view of the couplings between
the different entities. The ontology is intentionally not presented using
Unified Modeling Language or Entity-Relationship diagrams. These modeling
languages are subjects of ontological analysis themselves and therefore are
not suitable for expressing an ontology.

Following is a list with the main concepts discovered in the domain along with
their descriptions. The used BWW concepts are in \textit{italics} and
the domain-specific concepts are in \textbf{bold}.

\begin{description}

\item\textit{Class} \textbf{Style Guide} describes the coding practices
adopted  in the context of a single project, organization, community or
language. An individual Style Guide is a \textit{composite thing} built of
Conventions. Conventions in a Style Guide are interpreted
together to form a coherent set of guidelines.

\textit{Property} \textbf{Conventions} refers to the conventions contained in the Style Guide.


\item\textit{Class} \textbf{Convention} is a specific rule that imposes constraints on the CSS code. Conventions are the building blocks of Style Guides. An individual Convention is a \textit{composite thing} that contains a Context.

\textit{Intrinsic Property} \textbf{Description} contains the reasoning behind the Convention.

\textit{Hereditary Property} \textbf{Ignored Constructs} denotes the description of constructs that should be ignored while searching for the Convention's Context. It is inherited by the Context thing that builds a Convention.


\item\textit{Class} \textbf{Context} is a description of a \textbf{Pattern} that the Convention forbids. An individual Context is a \textit{composite thing} that comprises a \textbf{Constraint} or a \textbf{Constraint Combinator}. A violation is discovered when a Pattern in the current stylesheet fulfills all constraints specified by the Constraint or the Constraint Combinator.

\textit{Property} \textbf{Ignored Constructs} are descriptions of Patterns that need to be disregarded while searching for the current Context. In fact, the property denotes a collection of Contexts.






\item\textit{Class} \textbf{Constraint Combinator} is an entity that connects logically Constraints or other Constraint Combinators. An individual Constraint Combinator is a \textit{composite thing} that comprises one or more logically related Constraints and/or Constraint Combinators.

\textit{Property} \textbf{Number of Subjects} denotes the number of logically related Constraints and/or Combinators that are combined.

\textit{Property} \textbf{Combinator Type} is the particular way the Constraints are combined.


\item\textit{Subclass} \textbf{Negation Constraint Combinator} is a type of combinator that takes one Constraint or Combinator and returns the opposite Constraint or Combinator. An individual Negation Constraint Combinator is a \textit{composite thing} that comprises one Constraint or Combinator.

\textit{Property} \textbf{Number of Subjects} denotes the number of logically related Constraints and/or Combinators that are combined. In the case of the Negation Constraint Combinator, the Number of Subjects property is equal to one.

\textit{Property} \textbf{Combinator Type} is the particular way the Constraints are combined. Specifically, this type of combinator negates the Constraint or Combinator it takes.


\item\textit{Subclass} \textbf{Disjunction Constraint Combinator} is a type of combinator that takes two or more Constraints or Combinators and combines them using the OR logical operator. An individual Disjunction Constraint Combinator is a \textit{composite thing} that comprises two or more subjects.

\textit{Property} \textbf{Number of Subjects} denotes the number of logically related Constraints and/or Combinators that are combined.

\textit{Property} \textbf{Combinator Type} is the particular way the Constraints are combined. Specifically, this type of combinator states that at least one of the Constraints it combines need to be fulfilled.


\item\textit{Subclass} \textbf{Conjunction Constraint Combinator} is a type of combinator that takes two or more Constraints or Combinators and combines them using the AND logical operator. An individual Conjunction Constraint Combinator is a \textit{composite thing} that comprises two or more subjects.

\textit{Property} \textbf{Number of Subjects} denotes the number of logically related Constraints and/or Combinators that are combined.

\textit{Property} \textbf{Combinator Type} is the particular way the Constraints are combined. Specifically, this type of combinator states that all of the Constraints it combines need to be fulfilled.






\item\textit{Class} \textbf{Constraint} is a specific restriction that needs to be fulfilled. Constraints
are used in a Context to build a description of a Pattern. Constraints are
individual requirements that are imposed on Subjects. Based on the value of the requirement, there
are different types of Constraints represented below as subclasses.

\textit{Property} \textbf{Subject} indicates the thing that is being constrained.

\textit{Property} \textbf{Requirement} denotes the particular limitation applied to the Subject.


\item\textit{Subclass} \textbf{Existence Constraint} is a type of Constraint that requires existence of the subject. 

\textit{Property} \textbf{Subject} indicates the thing that is being constrained.

\textit{Property} \textbf{Requirement} denotes the particular limitation applied to the Subject. Specifically, the requirement is that the Subject must exist.


\item\textit{Subclass} \textbf{Comparison Constraint} is a type of Constraint that compares the subject to another value.

\textit{Property} \textbf{Subject} indicates the thing that is being constrained.

\textit{Property} \textbf{Requirement} denotes the particular limitation applied to the Subject. Specifically, the requirement is that the Subject must be related to the Value in a given way.

\textit{Property} \textbf{Value} denotes the value that is used for the comparison.


\item\textit{Subclass} \textbf{Type Constraint} is a type of Constraint that checks whether the subject is of a given type.

\textit{Property} \textbf{Subject} indicates the thing that is being constrained.

\textit{Property} \textbf{Requirement} denotes the particular limitation applied to the Subject. Specifically, the requirement is that the Subject must be of the given type.

\textit{Property} \textbf{Value} denotes the type that the subject should meet to satisfy the constraint.


\item\textit{Subclass} \textbf{Textual Form Constraint} is a type of Constraint that imposes restrictions on the textual representation of the subject.

\textit{Property} \textbf{Subject} indicates the thing that is being constrained.

\textit{Property} \textbf{Requirement} denotes the particular limitation applied to the Subject. Specifically, the requirement is that the Subject must be equal to the given Value.

\textit{Property} \textbf{Value} denotes the textual form that the Subject should meet for the constraint to be satisfied.


\item\textit{Subclass} \textbf{Set Membership Constraint} is a type of Constraint that requires the subject to be a member of a set.

\textit{Property} \textbf{Subject} indicates the thing that is being constrained.

\textit{Property} \textbf{Requirement} denotes the particular limitation applied to the Subject. Specifically, the requirement is that the Subject must be a member of the Value.

\textit{Property} \textbf{Value} denotes the set that the subject should be present at for the constraint to be satisfied.


\item\textit{Class} \textbf{Literal Value} is a thing that represents a constant value. It includes numbers, strings, boolean values, etc.

\textit{Property} \textbf{Value} denotes the specific value possessed by the literal.


\item\textit{Class} \textbf{Violation Log} is the final product of a violations search. An individual Violation Log is a composite thing that contains Violations.

\textit{Property} \textbf{Number of Violations} indicates the size of the Violation Log. 


\item\textit{Class} \textbf{Violation} A Violation occurs when a Pattern that matches the Context of a Convention is found.

\textit{Property} \textbf{Description} explains in natural text what causes the Violation. Typically, the Description is extracted from the Convention that the Violation breaks.

\textit{Property} \textbf{Position in Stylesheet} indicates the location of the Pattern that violates the Convention in the Stylesheet. 


\item\textit{Class} \textbf{Stylesheet} is the CSS code that needs to be checked for compliance with the Style Guide. An instance of Stylesheet is a composite thing that comprises a number of \textbf{Constructs}.

\textit{Property} \textbf{Checked} indicates whether a Stylesheet has been checked for compliance to a given Style Guide. 


\item\textit{Class} \textbf{Construct} is a part of the Stylesheet. It can refer to nodes in the CSS abstract syntax tree, concrete syntax tree and parse tree. Examples include whitespacing, indentation, comments, colons, delimiters, rulesets, declarations, etc.

\textit{Property} \textbf{Property} encapsulates properties of nodes specific to the CSS domain. For example, the type and the string representation of the node are its properties. Similarly, specific CSS Nodes can expose properties that are tightly coupled to the CSS domain, such as release date or vendor name of a CSS property.


\item\textit{Class} \textbf{Pattern} is a particular part of the CSS that matches the description of a Context. An instance of a Pattern is a composite thing built from one or many Constructs.

\textit{Property} \textbf{Number of Constructs} denotes the constructs that are contained in the Pattern.


\item\textit{Event} \textbf{Search for Violations in Stylesheet} occurs when the developer completes the search for violations in a Stylesheet, a Violation Log is created and the state of the Stylesheet is altered. When the search is completed, the Stylesheet is considered checked for compliance to the Style Guide.

\textit{New State} \textbf{Violation Log} \{ Violations = value \}

\textit{New State} \textbf{Stylesheet} \{ Checked = True \}


\item\textit{Event} \textbf{Context (Convention) Discovered} occurs when the Context of a convention is discovered and a Violation is recorded in the Violation Log. The state of the Violation contains its description and position in Stylesheet.

\textit{New State} \textbf{Violation} \{ Description = value, Position in Stylesheet = value \}


\item\textit{Event} \textbf{Stylesheet modified} occurs when the Constructs in the Stylesheet are modified. The state of the Stylesheet is changed to not checked for compliance.

\textit{New State} \textbf{Stylesheet} \{ Checked = False \}


\item\textit{Event} \textbf{Style Guide modified} occurs when any of the parts of a Style Guide are modified. This event changes the state of the Stylesheet to not checked for compliance.

\textit{New State} \textbf{Stylesheet} \{ Checked = False \}

\end{description}


Most of the definitions in the ontology refer to simple concepts that appear in the code conventions
domain. For example the concept of a Style Guide refers to a collection of coherent conventions. A
Style Guide on its own does not have any emergent or intrinsic properties and, thus, it is defined
through the conventions it comprises. Note that in reality a Style Guide may contain a number of
intrinsic properties, for example it may have an author and contributors. Such
properties, however, are not considered part of the specific domain, and thus lie outside the scope
of the ontology.

A Convention is defined as the building block of a Style Guide. However, the ontological concept of
a Convention is slightly different than what is used as a convention in the domain analysis section.
For example, domain analysis indicates that there are two types of conventions: forbid and require.
The former type of conventions describes directly their violations. The latter type describes a
pattern that, if found, puts additional requirements that must be met. In case these requirements
are not met, a violation is discovered. For example, the violation \textit{Do not use id selectors}
tells that id selectors are violations. The convention \textit{Strings should be with single quotes}
states that strings must have single quotes, and a violation is discovered if the found string does
not. These convention types are not related to the meaning of conventions but to the way they are
expressed. A convention with the same meaning could be expressed using both structures:
\textit{Strings should be with single quotes} and \textit{Forbid strings with double quotes}. Since
ontological concepts are concerned with the meaning of things and have to be independent of the
language used to express them, the ontology does not possess subclasses of Convention.

A Context is a description of things that are disallowed by a Convention, i.e. it states explicitly
what Patterns violate a Convention. In this sense, the meaning of a Convention is always expressed
through the possible violations of that Convention. A Context aims at describing a whole violation
pattern and consists of a single Constraint or a number of logically related Constraints. A
Constraint is a requirement that has to be fulfilled. Constraints can be combined
into complex constraints using Constraint Combinators. Since a Context may describe both a simple
pattern that can be expressed through a single constraint and a complex pattern that imposes a
number of constraints, the Context can comprise either a Constraint or a Combinator. 

As its name suggests, a Constraint Combinator is used to combine Constraints. That said, Constraint
Combinators could be recursive constructs and combine other Combinators. The Number of Subjects
property denotes the number of Constraints or Combinators that the current Combinator connects. For
example, the Negation Constraint Combinator always has a single subject, while the Conjunction and
Disjunction Constraint Combinator have two or more subjects. The Combinator Type property indicates
the particular operation used to combine the subjects. Based on the value of this property, there
are three subclasses of Combinators: Negation, Disjunction and Conjunction that correspond to the
logical operators \texttt{not}, \texttt{or} and \texttt{and}, respectively.

A Constraint refers to a single specific requirement. Every Constraint has a subject and a
requirement. The subject is the object that is being constrained and the requirement refers to the
specific limitation that is applied to the subject. There are different types of Constraints based
on the value of the requirement property. For example, a Comparison Constraint requires the subject
to be equal or greater than a given value and the Type Constraint requires the subject to be of a
particular type. The Existence Constraint requires the subject to exist.

Since Conventions are used to constrain CSS code, subjects are typically Constructs or their
properties. A Construct denotes a concrete part of the Stylesheet, e.g. newline, semicolon,
declaration, ruleset, etc. Each Construct exposes a number of properties that are tightly coupled to
its function in the stylesheet. For example, a property construct has properties
that indicate whether it is vendor-specific and its release date.

Patterns are composed of Constructs. The Constructs in the Pattern do not need to form a coherent
valid Stylesheet and they do not have to be adjacent or directly related. In fact, they could be
scattered across the whole Stylesheet. Patterns denote the concrete Constructs that match the
description provided by the Context of a Convention. In this sense, they are the specific instances
of Violations.

Definitions of the ontological concepts in the listing above often state that an instance of a
class is a composite thing that consists of other things. To provide a better understanding of the
way composite things are constructed, the same concepts are also expressed using BNF notation:

\begin{snippet}
\begin{verbatim}
style_guide    ::= convention+
convention     ::= context
context        ::= combinator | constraint
combinator     ::= (negation_combinator | disjunction_combinator | conjunction_combinator 
                 | constraint)+
violation_log  ::= violation*
stylesheet     ::= construct+
pattern        ::= construct+
\end{verbatim}
\end{snippet}

The grammar above illustrates that a Style Guide needs to contain one or more Conventions. A
Convention consists of a Context, which in turn, comprises either a Combinator or a Constraint.
Because a Context describes the whole pattern that is considered a violation, it can be expressed
through a single constraint or a combination of logically related constraints. A Combinator is a
recursive construct that can comprise Constraints or other Combinators. Different subclasses of
Combinator have different constraints on the number of subjects they combine. In general, they
require at least one subject. A Violation Log could exist without any Violations in the
cases when a Stylesheet is checked for conformance to a Style Guide and no violations are
discovered. Both Stylesheet and Pattern are defined through 1 or more Constructs.

While the above grammar presents the composition of things, it does not illustrate how things
interact with each other. To provide a better understanding of the dynamics between things defined
in the ontology, a graph of the system is presented in \autoref{fig:couplings}.

\begin{figure}[h]
  \centering
  \caption{Graph of the system}
  \label{fig:couplings}
  \includegraphics[width=0.8\textwidth]{couplings}
\end{figure}

According to the theory, a coupling occurs when the existence of a given thing affects the history
of another thing and, in turn, history is defined as the chronological ordered states that a thing
traverses~\cite{wand1990ontological}. Thus, in the domain-specific ontology a coupling exists
between the Style Guide and the Convention things, because the existence of a Convention alters the
state of the Style Guide. Similarly, a Context changes the state of a Convention. Because a
Constraint can appear both in a Context and a Combinator, it affects their states. In turn, a
Combinator alters the state of a Context. Thus, couplings exist between the Constraint, Combinator
and Context.

There are also couplings between Construct, Pattern and Stylesheet things. Both Stylesheet and
Pattern are composed of Constructs, and thus affected by their existence. Since a Pattern is a
specific occurrence of a combination of Constructs, it is also coupled to Stylesheet.

A Violation is coupled to a Violation Log, since the presence of a new a Violation alters the state
of the log. Further, a Violation Log contains information about the violations of a particular Style
Guide that occur in a specific Stylesheet. In this sense, a Violation Log is a function of a Style
Guide and a Stylesheet and it is coupled to both things.

There are a number of external events that can change the state of the system. An actor can initiate
search for violations, which affects the state of the Violation Log and the Stylesheet. If during
the search an actor discovers a violation, the state of the Violation is altered. Also, an actor can
modify the Stylesheet and the Style Guide. Thus, couplings exist between the Actor and the
Stylesheet, Violation, Violation Log and Style Guide.

\subsection{Ontological analysis}

The ontological analysis is a bidirectional mapping between the designed domain-specific ontology
and the domain-specific language. It consists of two mappings: representation and
interpretation~\cite{moody2009physics}. The former mapping matches the ontology to the language and
the latter --- the language to the ontology. Typically, ontological analysis is used to compare the
abstract syntax of the language constructs to the concepts of an ontology. However, the designed
ontology contains concepts that fall outside the scope of the abstract syntax. For example, the
notion of Violation Log has a corresponding class in the system, but that class denotes the
product of the violations search and is not part of the abstract syntax. The particular approach
chosen to conduct ontological analysis is to compare the abstract syntax of the language to the
ontology. Additionally, all remaining ontological constructs are mapped to their representation in
the whole system. For example, the ontological concept of a Violation Log is matched with the
Violation Log class in the analysis module.

\subsubsection{Representation and Interpretation Mappings} 

This subsection contains the two mappings between the modeling grammar and domain-specific ontology.
\autoref{tab:representation} presents the representation mapping. The left-hand side of the table
contains the ontological constructs in the order of definition and the right-hand side comprises the
corresponding modeling grammar construct. \autoref{tab:interpretation} presents the interpretation
mapping. The left-hand side contains classes from the abstract syntax, followed by classes that have
a representation in the ontology and the right-hand side contains the corresponding ontological
construct.

\input{tab-onto2grammar}
\input{tab-grammar2onto}

\textbf{Ontological Classes and Subclasses}

The ontological concept of Style Guide is represented in the modeling grammar as a Convention Set.
Similarly, the notion of Convention maps to the Convention class and the concept of Context maps to
the Pattern Descriptor class.

The ontological concept of Constraint Combinator appears in the modeling grammar as a union of
expressions: Not Expression, And Expression and Or Expression. The subclasses of Constraint
Combinator have refined and more specific mappings. For example, the Negation Constraint Combinator
corresponds to the Not Expression and the Conjunction and Disjunction Constraint Combinators map to
And and Or Expressions, respectively.

The ontological concept of Constraint appears in the modeling grammar as a number of Expressions.
These include Expressions used in mappings for the subclasses of Constraint: Comparison Expression,
Is Expression, Match Expression, In Expression and Node Query Expression. The mappings for most of
the Constraint subclasses are straight forward. For example, the Comparison Constraint is
represented as a Comparison Expression and the Type Constraint appears as an Is Expression.
Similarly, the Textual Form Constraint is a Match Expression and the Set Membership Constraint maps
to the In Expression. That said, the Existence Constraint requires further attention. As defined in
the ontology, the Existence Constraint requires the subject to exist. In the modeling grammar this
concept is indirectly presented using multiple structures. Nodes in a pattern are specified using
two ways: either through using Node Descriptor and Node Relations, or through Node Query Expression.
The modeling grammar describes the target nodes from the pattern and their parent nodes using the
former approach, and nodes that are nested in the target nodes --- using the latter. For example,
when the pattern that needs to be matched is a ruleset which contains a z-index property and appears
in a media query, the existence of the media query and the ruleset (and their relationship) is
described using Node Descriptors and a Node Relation. The existence of the property contained in the
ruleset is denoted using a Node Query Expression.

The ontological constructs of Violation Log and Violation are mapped to the Violation Log and
Violation classes, respectively. The notion of a Stylesheet is represented by the Stylesheet Node in
the solution and a Pattern is mapped to Css Pattern. The concept of a Construct is represented in
the abstract syntax tree as a Variable Expression. The reason behind this mapping is that in the
modeling grammar Variable Expression denotes only Constructs.

\textbf{Ontological Properties}

The majority of the ontological properties are mapped to a single construct in the solution. For
example, the Description property of Convention class in the ontology is directly mapped to the
Description property of the Convention class in the modeling grammar. However, some of the property
mappings are not that obvious. For example, the ontological property Conventions of class Style
Guide is represented by a combination of properties in the solution: Contexts of Convention Set and
Conventions of Context. Also, the notion of Ignored Constructs maps to the Context class in the
solution. The reason for these mappings comes from the fact that the solution groups together
conventions with identical ignored constructs. As stated in the ontology description, each
convention specifies a set of constructs that need to be ignored while searching for its violations.
For example, while evaluating the constraints of conventions related to newlines, the indentation
constructs are typically ignored. Because the ignored constructs are similar for most of the
conventions, the modeling grammar groups conventions that use the same ignored constructs into
contexts. Thus, the Convention Set contains Contexts and a Context specifies the ignored constructs
of all conventions that it contains.

The Number of Subjects property of Constraint Combinator is mapped to the operands of the
expressions that correspond to the Constraint Combinator. Similarly, the Subject and the Value
properties of a Constraint are mapped to the operands of the expressions that map to Constraint.

The ontological property Violations of the Violation Log construct appears in the modeling grammar
as property Violations of the Violation Log class. The Violation class exposes Description and
Position properties that map to the ontological properties Description and Position in Stylesheet.
The Checked property of Stylesheet does not have a representation in the system. The property
Property of Construct is denoted in the abstract syntax using a Call Expression.

\subsection{Ontological Evaluation of the System}

The primary purpose of the representation and interpretation mappings between
the ontology and the modeling grammar is to discover discrepancies between the
two entities. The four types of ontological anomalies are considered in the
following subsections.

\subsubsection{Redundant Constructs} 

Construct redundancy is a type of discrepancy in which more than one modeling
construct can represent a single ontological construct. The representation
mapping illustrates that there are three candidates for this anomaly.

First, the Conventions property of Style Guide is matched to Contexts property
of Convention Set and the Conventions property of Context. Such mapping is
required since the modeling grammar groups Conventions that share the same
Ignored Constructs in a Context. Thus, a Style Guide in the modeling grammar
does not possess conventions but a number of Contexts that, in turn, contain
conventions. In this sense, the properties Contexts and Conventions together
represent the concept of Conventions.

Note that redundancy occurs when the two grammar constructs can independently
represent the same ontological concept. In the specific case, however, none of
the constructs taken individually can express the property. It is their
combination that represents the concept. Mapping a single ontological concept
to a combination of modeling grammar constructs is an accepted approach and
has been used in multiple studies~\cite{gehlert2007toward}. Thus, the two
constructs are not considered redundant.

Second, the Comparison, Is, In, Match and Node Query Expressions map to the concept of Constraint.
As defined in the ontology, a Constraint is a class that has multiple subclasses depending on the
specific requirement they enforce. In this sense, Expressions that map to any subclass of
Constraint, also map to the Constraint class. This is why, the Constraint corresponds to a union of
all mappings of its subclasses. Thus, the expressions are not considered redundant.

Similarly, the Constraint Combinator is mapped to the Not, And and Or Expressions. Again, the
mapping is a combination of the individual mappings of the Constraint Combinator subclasses. In
this sense, the expressions are not considered redundant.

Third, the Existence Constraint is mapped to the Node Descriptor, Node
Relation and Node Query Expressions. Existence Constraint is a type of
Constraint that requires the Subject to exist. For example, the convention
\textit{Use a fallback property for RGBA and HSLA values} requires the
fallback declaration to have the same property as the matched declaration and
the value of the fallback declaration to be different than RGBA or HSLA.
However, before these, the convention requires the fallback declaration to
exist.

In the modeling grammar, when a Pattern Descriptor refers to multiple nodes,
the presence of a Node Descriptor denotes the existence of CSS Node and the
Node Relation specifies how the Nodes are connected in the Pattern Descriptor.
As described in the domain analysis section, each Pattern Descriptor has one
of more target nodes. These are the specific nodes that need to be iterated. While
the Node Descriptors and Node Relations describe the target nodes in the
Pattern and their parent nodes, the Node Query Expression is used to describe
parts of the pattern that are nested in the targets.

As with the previous two cases, the ontological concept cannot be represented
by Node Descriptors and Node Relations or by Node Query Expressions taken
individually. Their combined use allows expressing patterns. For this reason,
the constructs are not considered redundant.


\subsubsection{Construct Overload}

Construct overload emerges when a single modeling construct can represent a
number of ontological constructs. In the interpretation and representation
mappings every language construct is assigned a single ontological construct.
In this sense, there are not candidates for overload discrepancy.

\subsubsection{Construct Excess}

Construct excess is a discrepancy in which a modeling construct does not have
a mapping to an ontological construct. In the interpretation mapping all
constructs that belong to the abstract syntax are mapped to an ontological
construct. Thus, there are not candidates for construct excess from the
abstract syntax.

\subsubsection{Construct Deficit}

Construct deficit appears when an ontological construct does not have a
corresponding modeling structure. A candidate for such discrepancy is the
property Checked of class Stylesheet as it appears without a matching
construct in the system. However, maintaining the status of a Stylesheet is
considered outside the scope of the system. Such functionality is highly
dependent on the specific information offered by the IDE or text editor.
Support for this property remains in the environment of the system. In this
sense, the candidate is not considered an occurrence of deficit.


\subsubsection{Results}

In this section are presented the interpretation and representation mappings
between the modeling grammar and the designed domain-specific ontology.
Further, all types of discrepancies are analyzed and argumentation is provided
why they should not be considered anomalies. Having the analysis in mind, it
can be concluded that the ontological analysis provides sufficient evidence to
consider the designed system both ontologically clear and complete.