Some MarkupCentric approaches are attempts to introduce the same semantics expressed using the EmbeddedCode approaches, but in a way (from the point of view of the target markup language) that is less intrusive than embedding the code.
A subset of such languages extend the markup language's own vocabulary with additional control flow statements and are called control flow analogies here. (See PageComposition for another, related category.) The semantics of these statements is the same as those used to control flow in conventional programming languages: if statements control the conditional inclusion of parts of the template, and looping statements allow one to include a chunk of the template several times.
The extension of the markup language is usually done either by introducing added tags to the markup language, or by adding attributes to existing tags. The motivation behind this seemingly cumbersome notation is that the source code of the template would then be valid according to its markup language (usually some form of XML, such as XHTML), and thus be editable in WYSIWYG editors1. Java Server Pages (JSP) restricted to its JSP Standard Tag Library (JSTL) is an example:
1 <body>
2 <c:foreach var="item" items="wordList">
3 <p>Word: ${item}</p>
4 </c:foreach>
5 </body>
1 A note about such WYSIWIG editors: WYSIWYG editors will not display the page resulting from executing the template being edited. They can only show the logical structure of the source code of the template itself---which also happens to be valid XHTML. To get around this problem, some template languages are designed so that their source looks like an example of what may be rendered, given some execution of the template. This goal can of course not be wholly attained, since a template, by nature, does not evaluate to a static document.