Coming after "Content Types," this concept ("Markup Languages") explores the applications of XML that implement each defined Content Type. This topic also addresses the other "MLs" used in this site build system, further down the line as the content moves from "Content Type" markup ("BusinessML") all the way to presentation markup ("SiteHTML," ultimately).
![[Note]](images/note.png) | Note |
|---|---|
Before we move into the MLs here, it is interesting to note that next in line in our review of concepts we will be looking into the Document Type Definitions (DTDs) that "implement" each Markup Language, and following that we'll go into the actual Elements which in turn "implement" the DTDs. These comprise a sort of "side tour," which is also a "hierarchical descent," but down a different path. It differs from the overall "top-down tour" we have been on, in that the topics addressed in this "side" tour are largely behind-the-scenes, and do not appear as visual elements of the page construction. | |
![[Tip]](images/tip.png) | Tip |
|---|---|
Interestingly, the two "tours" converge when we finally get to the ultimate nested object: the Text contents of those Elements that do hold (not all do!) "PCDATA" (in XML parlance, "parsed characater data") (a.k.a. "text"). This of course gets seen ("is visible"), as the words on the website page. | |
As noted, the single topic "Markup Languages" in fact embraces a set of four XML vocabularies that are used in sequence within this site build system, as Modules are processed along a "pipeline" that transforms them from source content "trees" into final presentation "rectangles."
In each ML, the data to which the markup is applied is the same: it is the Module-level "unit" of content. There is a hand-off from one ML to the next of the same content, just marked up differently. (Also along the way, various content element selections may be made (suppressing certain administrative elements from final presentation, for example.)
Figure 3.35. Copy Processing
Copy Processing, with invented (fictitious) elements. (See also the figure for Copy Processing, with Transformations (in the XSLT Pipeline section).)
The overall Module structure, as implemented in the Elements that make up the Markup Language (ML), is divided into two significant parts: the management elements and the body elements. These can be thought of as the "metadata" and "data." In BusinessML (the "semantic" ML), these two parts have as "containers" the two elements that are immediate children of the "document element" (which is <content>), namely: <contentInfo> and <contentBody>. For both StructureML and StructureLayoutML the corresponding elements are <moduleInfo> and <moduleBody>. (The final SiteHTML has no corresponding "metadata" element container; it's just the data (information, or content) at that point—no further requirement for management artifacts. (An attribute of the outermost <div> does hold the single piece of meta-information, the <instanceName> (e.g. <div id="ct01_1car_2sel_index"> ).)
BusinessML is the markup language that makes it possible to create new, proprietary named Elements ("tags") that permit you to capture (via "mark up") the semantic meaning of the business information found in the module content (if any can be so identified). It is the first ML in the sequence, and it serves as the "source data" version of the marked up content. Being focussed on the meaning of the content, and using only very simple structural markup to capture inner structure, it is not at all concerned with final presentation. BusinessML is the "database" of content to be carefully maintained, as under version control.
| Note |
|---|---|
Some content modules will really have no particular "semantic" information to be captured in named elements. These get the Content Type 'ct01_general,' and the BusinessML used to record them is in fact quite close to the StructureML used after the 1st "hop" (transformation) into the 2nd ML. The example seen in the figures below is in fact of type 'ct01,' and was selected more for the tabular data it houses, than the use of semantic tags. The utility here is that we see an example of the HTML <table> element used correctly: that is, to actually hold tabular data (take a look at the final rendered HTML further below), not to provide "pseudo-structure" to the page. For a better example of actual semantic tags in BusinessML transformed to structural tags in StructureML, see the (less visual, far more code-details) walk-through of the XSLT transformation of Content Type 70 ("Highlights"). | |
| Tip |
|---|---|
At a first glance at the <table> in the figure below, it can seem that there are many overly presentational details captured in its markup: cellspacing; cellpadding; colspan="2"; <img src= height=>; etc. While perhaps a few of these could have been re-factored out of the XML and into the XSLT (via the "Presentation Type" and "Presentation Style" mechanisms available in this site build system), in fact much of this markup is appropriate here. This you could say is the "double-edged sword" in this system—always available to the website markup specialist there is a "back-door," even in BusinessML, to do with HTML whatever is required. This is both a good thing, and perhaps a bad thing, but it's more important that the "good thing" aspect of it be there, than to suppress that ultimate flexibility. | |
With StructureML we step away from proprietary, semantically meaningful tags and towards strictly structural elements. This is especially true in the container element <moduleBody>, which is now all in "ca. 1994 HTML" markup, for structure only, regardless of how many proprietary semantic elements it had in BusinessML. The only exception is the non-HTML (and temporary) "marker" element <eza zone="" position=""/>; these are used to position Place-able Elements in the transformation to the next ML (explained further below).
The "info" (<moduleInfo>) portion maintains the necessary management elements, including all the "type" information: 'content type,' 'module type,' and 'presentation type' (<moduleInfo contentType="ct01" moduleType="mt01" presentationType="pt02_blue">). This is carried over from two originating sources: 1) the unchanging 'content type' information is in the BusinessML module (/mlnmdev/BusinessML/ct01_1car_2car_career-receptions.xml), while 2) both of the potentially changeable decisions about 'module type' and 'presentation type' are kept separately, in the "EZA Recipe" file (e.g. /mlnmdev/ezaRecipes/eza-ct01_general-mt01-pt02_blue-recipe_1.xml).
StructureLayoutML is entirely similar to StructureML, in terms of those elements that mark up the content closely (e.g., that hold the text content (#PCDATA) directly, and that provide the essential "block" content structure (headers, lists, paragraphs, etc.)). What StructureLayoutML then adds is the "structure" as seen at the presentation level: the Module Layout. This structure is implemented by the HTML <table>(s) that hold the Elements of the BusinessML "Content Type" in a "Module Type" display layout. (Not to be confused with the layout for the overall Page.)
Looking back, StructureML (SML) held the content in the same way that BusinessML (BML) did: without recourse to <table> markup for layout, but instead in simple "Flow" down the page of the blocks of content, stacked up. The first transformation (BML-to-SML) altered the tag names (from semantic <highlight> to structural <li>, for example), but left the overall structure unchanged. The second transformation (SML-to-SLML) into StructureLayoutML (SLML)—with the aid of the EZA mechanism—leaves unchanged the tag names (<li>), but alters the overall layout structure (namely, by introducing some where there hadn't been any before: the HTML <table>(s)).
"SiteHTML" is HTML, that is, it follows theW3C XHTML-1.0-Transitional DTD. The point of interest here is less with the resultant Markup Language in which the Module of content finally "lands" (which is simply HTML), as with the final transformation XSLT that renders it into that final HTML, which happens to be, by definition, that subset of the W3C HTML that is actually used on the site: "SiteHTML."
It is this final XSLT (/mlnmdev/xsl/sh01_general.xslt) where the web site developers apply any and all presentational approaches to render the desired look + feel for the site.
The input to this transformation will be the essential business information, as now shorn of proprietary semantic tags, and instead now wrapped in essential structure (the "close-in" elements, holding text and basic inherent structure (<p>, <h3>, <ul> etc.)), which in turn is now wrapped in "presentational structure" (the use of HTML <table>s for layout), and is ready for the final transformation into whatever final HTML and CSS techniques are required to achieve the proper look + feel.
If and when the overall look + feel for the web site were to change (site re-design), in principle the single file sh01_general.xslt (plus of course the CSS) would be modified a great deal, while all other files—both XML and XSLT—might be left as-is. Now in practice there may indeed be some presentation information tied into the markup of the first three MLs, such that they too require changing. But with the design of this system, you are at least provided with an overall mechanism to avoid as much as practicable the need to ever alter the source data BusinessML and the first and second transformation XSLTs (ct*.xlst and mt*.xlst). (Recall that the second and third MLs are derived files, so altering them is only done via the XSLTs, not edits on the XML.)
| Tip |
|---|---|
This discussion is at the Module level, not the Page level. With a site re-design the set of Page Layouts (/mlnmdev/SiteHTML/PgLayouts/pl*.html) would also of course be re-visited. To address this same question (of site re-design) regarding the Navigation components, the source XML (/mlnmdev/BusinessML/NAV1.xml and NAV2.xml) shouldn't have to change (with the obvious exception of whatever actual data changes you had), while the single XSLT that processes each would change, of course, but only in the presentational parts of that XSLT, not the fundamental algorithm of the XSLT that proceeds through the hierarchical structure of the source data XML. | |
