The Element "highlights" (plural) is a "place-able" Element for this Content Type. This means you may determine in which Module "Zone" you wish it to appear ("Assign" it to).

Match on "highlights" (plural) element.

Run the utility template in ct00_core.xslt called getElementEZA.

This retrieves the "Assignment" information about which "place-able" "Element" goes in which Module "Zone". (EZA = Element-Zone Assignment)

Match on "highlight" (singular) element.

Variables for the "path" plus "Recipe" (filename) have been established, such that the document() function can open the ezaRecipe file. The XPath gets down to the nodeset of individual "assignments" ('eza' element).

When the passed-in elementName matches the elementName attribute in the 'eza' element, we've got our match.

The "Zone" values match the Module Type cells, and are named simply 'A', 'B', etc.

The "Position" value is the numeric position (stacked, top-to-bottom) within a Zone; numbered simply '1', '2', etc.

The "Presentation Style" for a particular BusinessML element is often the default "SiteHTML" style as found in the sh01_general.xslt, for the "StructureML" element it is transformed into (e.g. <headline> might become <h3>, or even more generically <div>).

But if the presentation needs to differ from the default, a "flag" may be set here in the ezaRecipe file: in this example "ps70" signifies the element <div> will be processed differently. See the sh01_general.xslt snippet below.

Container for possibly multiple 'eza' elements, one for each "place-able" element in the Content Type Module (BusinessML). In this case, one place-able element only: 'highlights'.

The key information carried by the ezaRecipe: which Element; which Zone in the Module (which <td> table cell, effectively) (lettered 'A', 'B', etc.); which Position within that Zone (stacked up, simply)(numbered '1', '2', etc.); and (optional) any Presentation Style.

Note

Not discussed here, but can be seen in the code: there is also the "Presentation Type". This is a higher abstraction of indicating style decisions, as it applies a single "code" or "flag" to the entire Module (e.g. 'pt70'), as opposed to a single Element (as we have here, with @presentationStyle='ps70' for the Element 'highlights'). [You may think of the term "Type" as signifying an entire Module, as we do for "Content Type" (BusinessML module) and "Module Type" (StructureML module).] So, if a given Module has to apply a special presentation to more than one Element, you may do one of two things: create multiple @presentationStyle attributes, each of which can be tested individually in the sh01_general.xslt (see below for example) OR you may approach the design decision differently and devise a <presentationType> element value that will apply to all the elements in the Module. You would then need to program the sh01_general.xslt to present each of these elements properly, testing for each on this single presentationType "flag," as determined at the Module level, rather than testing on several different flags as determined at the Element level. Note: The current project did not make use of this presentationType (Module-level); it did use the presentationStyle (Element-level).

	Tip
	Again, please recall these special presentation mechanisms are only used when you want elements to receive a look + feel handling in the final SiteHTML XSLT (sh01_general.xslt) that is different from the default look + feel. Usually, most of a site's content would call for no need for these "presentationStyle" and "presentationType" mechanisms.