For the best understanding of IKAT, it would probably be best to go to DansIKATExplanation (Dan's comment - this page is an attempt to come to a clear description of IKAT by Dan having a go at what he understood). Dan's explanation is much clearer and direct than anything I could come up with, and talks about green strawberries. Hopefully we will have lots of examples on this site soon, since trying to understand the algorithm in itself is pretty pointless without some idea of what it enables you to do.

---

Antranig's original explanation:

The IKAT algorithm is described here - not in pseudocode order, but in an order that involves as few forward references to concepts as possible. For those interested in a more code-based presentation I can only recommend they look at the ViewTemplate.java file where it is defined.

1. The "base state" of IKAT is to be rendering linearly through the template file, simply copying from input to output, until a tag mentioning the rsf:id attribute is met. The "base state" is also referred to as "template-driven rendering".
2. At any time in the "base state", IKAT has in its hands the "current container", which is an instance of UIContainer in which child components are to be looked up.
3. Also at any time in the "base state" IKAT is aware of both the current nesting depth (in terms of template XML tags) and also the initial nesting depth at which it entered the base state.
4. IKAT begins in the "base state" at the head of the "root template" file, which is specially designated by the lookup from the TemplateResolver. There may be several other template files also added to the resolution set. In this initial state, the current container is set to the root container of the View object accepted as argument.
5. When IKAT encounters an rsf:id, it will take one of three actions depending on the value of the attribute.
   1. For an rsf:id containing neither a colon : nor an equals character =, IKAT will interpret the attribute value as the ID of a leaf component, the Peer of the current template tag, which must occur as a child of the current container. IKAT looks up the component, and passes it together with the current template position to the current RenderSystem, which will look up a suitable ComponentRenderer based on the type of the component, and write transformed template data to output based on an inspection of both the template data and component field values. After leaf rendering, IKAT continues in the base state at a new template location determined by the renderer (either after the opening tag, or after the closing tag just seen in the template).
   2. For an rsf:id containing an equals character, IKAT extracts the suffix following the = (prefix reserved for future expansion, currently scr) and uses it as an index into a request-scope container of StaticComponentRenderers. Similar to the case above, IKAT invokes the SCR and steps along in the template, remaining in the base state.
   3. For an rsf:id containing a colon, IKAT leaves the base state and enters the "extended state", also referred to as "component-driven rendering". At this point IKAT assembles the list of all children of the "current container" sharing the prefix of the ID (before the colon). Each of these children must themselves be a container whose ID will necessarily contain a colon. IKAT iterates over each of these "prefix-sharing children" (PSC), executing the following steps for each one:
      1. For each (PSC) of the current container in the "extended state", the IKAT function call is invoked, the key step of the IKAT algorithm. IKAT assembles a resolution set consisting of ALL open tag locations in ALL templates which share the prefix of the PSC. The "best match" is chosen by a procedure explained on the IKAT function call page. The current template location (index and file) are pushed on the stack, and IKAT resumes execution in the "base state" with the current container set equal to the PSC.
      2. When the "function call" returns, and there is at least one further child left, IKAT will briefly enter the "glue state" where it scans along the template simply copying all data it finds until the next instance of a tag with the current prefix, OR ELSE falls below the nesting depth at which it started doing so[1].
6. If while in the base state, IKAT encounters a tag with a nesting depth lower than the initial depth, the "function call" will "return" - IKAT will restore the values of the "current container", template index pointer and initial nesting depth from the stack frame, and resume scanning in the "extended state" at the restored index pointer.
7. If while in the base state IKAT falls off the end of the root template file, rendering is concluded.

---

[#1] NB - there is some scope for fusing the "glue state" with the "base state" if we can think of any benefits to this. Currently "glue" is not allowed to contain further components, and I can't at the moment think of any reason to allow anything so confusing. The "glue state" is meant to allow "spacer" components between repeated elements to be encoded in the template, and has been enormously slimmed down from an initial highly ambitious scheme whereby all possible transitions between child suffices would be mapped within the template in order to locate much more relevant "multi-coloured glue". So far the only "glue" that has ever been used is rather drab and grey consists of an   or a hyphen...