Building a web site using XML and XSL allows for a clean separation between business logic, content and presentation:

A different, more detailed version of the previous figure, which applies to the Nun.Me.Shu framework, is shown below:
Explanation of the above figure: Static web page content in the Nun.Me.Shu framework is stored in XML files. Templates for transformation and layout are stored as XSL files. XSL files need to include site-wide content: the information for navigation, header and footer is stored as an XML file; small text fragments are stored in an ENT file. Two other ENT files store specific environment information (mainly URLs) and layout information respectively. An XSLT processor uses the information in the XSL files to transform the XML files into HTML. The HTML file references GIF or JPG images, JavaScript JS files and Cascading Stylesheet CSS files that are used by a browser to display a web page on a user's computer screen.

The "XSL stylesheet" is modular for understandability and expandability, and consists of the following files:
    - main.xsl [view sample] (the main stylesheet, basically just some imports and includes)
         |- common.xsl (global variable definitions and common templates, shared by the other stylesheets)
               |- debug.xsl [view sample] (debug templates)
         |- amazon.xsl [view sample] (common templates, but specific to amazon's web service)
         |- moreover.xsl (common templates, but specific to moreover's web service)
         |- yahoo.xsl (common templates, but specific to yahoo's service)
               |o yahoo.xml (content for yahoo directions form)
         |- pagelayout.xsl (pagelayout for the html page)
               |o wrapper.xml [view sample] (content for the wrapper components)
         |- wrapper.xsl (templates for the wrapper components of a page)
         |- (sp_content.xsl) (site-specific templates for the content component of a page)
         |- (sp_wrapper.xsl) (site-specific templates for the wrapper components of a page)
         |0 defs_env.ent [view sample] (environment specific entity definitions)
         |0 defs_layout.ent [view sample] (layout specific entity definitions)
         |0 defs_content.ent [view sample] (content specific entity definitions)
This modular design is based on server-side page rendering. The resulting stylesheet contains all available templates, and is thus relatively large (110K - including lots of comments). Server-side this stylesheet is compiled and kept in memory; size is not so much an issue, and is compensated by the benefit of having just one stylesheet for all web pages.
In case of client-side rendering, the single stylesheet is probably too big. In that case it could be modularized even more (split common.xsl in separate files for each functional section, -paragraphs, links, graphics, lists, forms-), and each page could have a trimmed down version of the complete stylesheet. This requires more effort in defining the right stylesheet for each page, but leads to less data transfer to the client. (I'm still on a 56K modem, despite my Internet development work, so I assume that still as the standard.)

Note that the stylesheet has build-in debug templates, to flag unmatched elements in the XML files and to allow for run-time display of debug information.
The stylesheet has build-in templates to process pre-styled (X)HTML components. This allows for an architecture in which some of the components of a page that are fairly static are pre-styled and cached as (X)HTML, so that the stylesheet can simply copy them.

Any URL or environment-specific identifier is defined in the defs_env.ent Entity Definition file, which is referenced in the main stylesheet. In a promotion process (development -> QA -> production), only this one file might have to be changed. My own development environment reflects my ISP's hosting environment; consequently I do not have to change anything when promoting files from my personal development environment to my ISP's hosting environment. There are no hard-coded URLs in the stylesheet. Therefore, if at some point in the future the directory structure of the site would change, only the defs_env.ent file has to be updated accordingly.

The XML elements to describe the content are kept as general as possible [view sample DTD]. For instance, any type of paragraph is indicated with a <para> element. Specification of the specific role (and thus styling) of a paragraph is indicated with a role attribute. Another example, a frequently-asked-questions element was not called <faq> or something similar, but was called <indexedlist> to allow it to be used for other types of list with an index, not just for FAQs.
Where ever possible, elements are re-used. For instance, there is a <graphic> element to describe graphics and images. There also is a <graphiclist> element which can be used for instance to create photo-album pages. This <graphiclist> element has the generic <graphic> element as a child. This provides consistency for a content editor, and keeps the amount of templates in the XSL stylesheet to a minimum.

The Nun.Me.Shu framework supports a "Zen"-like approach to web design:

• page layout and page appearance is simple and consistent
  There is one basic stylesheet that is used by all pages.
  Pages have a low header, to allow for a maximum amount of space to be used by informational content. Navigation is in a consistent place, and in one place only (no duplication of navigational elements across a page). The home page has relevant info about the site (most people abandon a site on the main page if they don't see the information they were looking for). Each page has an introductory paragraph.
• content description (DTD, XML) and transformation templates (XSL) are as simple as possible
  There is one DTD [view sample] for all web pages, and there is just one stylesheet. The DTD is very generic, and the stylesheet templates are kept very generic (and "push" oriented) as well. Implementation of web services is hidden from content editors behind simple XML elements.
• use of a minimal set of open source and open standard software technologies
  Content is defined in XML, the emerging standard for data storage and transfer. Content is transformed into HTML for display on the web using XSL stylesheets. Web pages only use JavaScript and Cascading Stylesheets for additional functionality and styling. The web site is hosted in a Linux environment with Java-based Apache web server, Tomcat servlet container and Cocoon XML publishing servlet.
  (That's all; no complicated EJB-based application servers, Frontpage extensions, proprietary data formats like Flash, or proprietary application builders like ColdFusion or StoryServer.)
• presentation is information oriented; no wild animations or advertising
  Although any valid XHTML is accepted, there is no build-in support for Flash, Java applets, sound or video for instance.
• basic functionality is pure HTML; JavaScript (DHTML) is used for non-critical functionality only
  The use of JavaScript (DHTML) can improve the user experience, for instance controlling the dimensions of a separate floating window, or adding a scrolling index to a page (see the FAQ page). However, JavaScript is used such that it never impacts the basic functionality of the site. Browsers that do not support JavaScript or that have it turned off can still access all content.
  An example of the use of JavaScript without compromising basic functionality is in the definition of a link that opens a new window:
  <a href="some_url.html" target="float"
  onclick="javascript: floatWindow('some_url.html','float','400','500'); return false">
  This link works with and without JavaScript. With JavaScript, the "onclick" event will be triggered, which calls a function to open a new window with special characteristics; the "return false" statement causes the href and target attributes to be ignored. Without JavaScript, the href and target attributes are used and the page is opened in a new window; the characteristics of the new window can not be controlled but at least the page will be displayed.