Overview

Frequently a company wants to publish its web content to multiple sites and/or multiple devices, where a site is defined as a unique set of viewable pages.  Some common reasons why a company may want to repurpose its content to multiple sites include:

• Support for both text and HTML versions
• Company internal and external versions
• Syndication (with or without cobranding)
• Support for different media, including different browsers or different devices such as WAP.

In most publishing systems, support for multiple devices and presentations entails publishing multiple sites--one site for each combination of presentation and device type. In the Ingeniux CMS publishing paradigm, by contrast, content is published once, with presentation being determined dynamically at the moment of request.  The data sent back to the client, and how this data is presented on the client, depends on the business rules associated with the client making the request.

In Ingeniux CMS, there is really little distinction between publishing, cobranding, device support, and syndication--they are all variations on the same theme, and use exactly the same underlying technology. In Ingeniux CMS, content is separated from presentation by putting all content--and only content--in XML files in a central content store, and using XSLT stylesheets for the presentation layer. In the case of syndication, XSLT is used to tailor published data for the purpose of data exchange rather than presentation. In the case of cobranding or device support, XSLT gives the proper presentation for each device and brand.   

There are two distinct techniques for dynamically tailoring content in Ingeniux CMS. The first is dynamic stylesheet binding. The content of pages and components is stored in XML in a single published location,  and XSLT stylesheets are bound to the data at the moment of request to determine the presentation. In this way, the data sent down to the client can be very finely tailored to the needs of that client, in terms of the display characteristics of the device, branding and formatting, and the amount and type of information appropriate to that client. Thus, from a single store of content, you can configure business rules so that different devices (browser, PDA, set-top box, WAP, i-mode) receive a different subset of data, all formatted in an optimal way for that device, and even create multiple brands or presentations for each device. This technique is most useful when trying to provide content to widely disparate devices and presentations.

The other technique makes use of the Cobrand and CobrandGroup components. This approach is most useful when the difference between the various presentations is relatively small and the number of different presentations is relatively high.

Administrators of the Run-Time Ingeniux Server can configure business rules for dynamic content and stylesheet selection based on user agent and/or identity of the requesting site. This will be explained below.

Dynamic Presentation Using Dynamic Stylesheet Binding

There are a number of different scenarios to consider for the cases where it is deemed optimal to use dynamic stylesheet binding.

Single Site, Single Browser, Single Stylesheet per Page

In the simplest scenario, a company may simply want to publish a single version of a site and target it as a single browser only.  This might be the case for a company Intranet site, where it is possible to standardize on a specific browser.  In this situation there is no configuration necessary.  When a request for an XML page comes in from a site, it is retrieved from the xml directory.  The stylesheet specified in the <?xml-stylesheet?> processing instruction at the top of the XML file (which can be configured through the Publisher UI), is retrieved from the stylesheets directory and bound to the XML file.

Multiple Browsers/Devices, Multiple Stylesheets per Page

When tailoring content for different device types or radically different cobrands, the best strategy is often to apply a different stylesheet depending on the browser that will be rendering the page.  (Here, the term "browser" is defined to include not just the typical browser that runs on a personal computer, but rather includes any new devices for which there is an emerging standard for web-based communication, including cell phones and PDAs.) By binding the XML to a device-specific stylesheet, you can customize the content to match the unique features and format of each device, rather than trying to force content appropriate to a Web browser onto, say, a cell phone.

Most of the business rules pertaining to dynamic presentation and stylesheet mapping are contained in a configuration file named ssmap.xml, located in the stylesheets directory, which determines the presentation that any particular client will see at page request time. Its format can be seen from the following example, which we will refer to in the remainder of this document:

<?xml version="1.0"?>
<xPressStyleSheetMap Version="1.0">
 <UserAgents>
  <UserAgent SearchString="MSIE" Name="msie" />
  <UserAgent SearchString="Mozilla" Name="mozilla"/>
  <UserAgent SearchString="Netscape" Name="netscape"/>
 </UserAgents>
 <Sites>
  <Site SearchString="computerstop.com" Name="cs" SiteGroup=""/>
  <Site SearchString="officedepot.com" Name="od" SiteGroup=""/>
  <Site SearchString="jane.com" Name="jane" SiteGroup="group1"/>
  <Site SearchString="john.com"  Name="john" SiteGroup="group1"/>
  <Site SearchString="Compaq.com" Name="compaq" SiteGroup="group2"/>
  <Site SearchString="Exxon.com"  Name="oil" SiteGroup="group2"/>
  <Site SearchString="CityOfSeattle.com" Name="wetplace" SiteGroup="group2"/>
  <Site SearchString="cannon.com" Name="cannon" SiteGroup="group3"/>
  <Site SearchString="nikon.com" Name="nikon" SiteGroup="group3"/>
 </Sites>
</xPressStyleSheetMap> <o:p></o:p>

The <UserAgents …> section in the ssmap.xml file above is used to map user-agent substrings to a tag name.  In the example above, the tag name ‘msie’ represents any user-agent string that has the sub string ‘MSIE’ in it.  If you want to apply a user-agent-specific stylesheet to an XML file, then you would create a stylesheet with the same file name as the default, but append the user-agent tag name.  For example, if you wanted an IE-specific version of a stylesheet called "story.xsl," you would create a file named "story-msie.xsl."

When the Ingeniux CMS Server is rendering the page it will map the current user agent to a tag name and then determine whether a user-agent-specific version of the style sheet exists, and if so, update the XML-stylesheet processing instruction to use that style sheet. In this way, radically different presentations may be achieved from a given store of data.

Site-Specific and Class-of-Site-Specific Configurations

Another type of dynamic presentation is the ability to dynamically render web content based on the client URL requesting the page. This is the classic cobranding scenario, where a company may wish to give different branding to a given site depending on the requesting URL, to accommodate different business needs, language requirements, etc.

There are two levels at which a company may want to selectively render content:  1) Site-specific: a request from a specific site needs a site-specific action, with a one-to-one mapping between a request and the action taken; and  2) Class-specific: request are handled in the same way for a class of sites.  In this case, a request from multiple sites will result in the same action taken.

The <Sites …> section in the ssmap.xml file allows users to create a mapping between different client requests and a tag name used to represent the client.  This tag name is used for both dynamic inclusion of xml web content and dynamic selection of XSL stylesheets. 

The format for this section of the property file is as follows:

<Sites>
   <Site SearchString="computerstop.com" Name="cs" SiteGroup=""/>
   <Site SearchString="Compaq.com" Name="compaq" SiteGroup="group2"/>
  <Site SearchString="Exxon.com"  Name="oil" SiteGroup="group2"/>
</Sites><o:p></o:p>

The ‘SearchString’ attribute specifies the sub string to match in the client URL.  If a match is found then the site is mapped to the tag name ‘cs’, specified by the ‘Name’ attribute.  The ‘SiteGroup’ attribute specifies the SiteGroup that a Site belongs to.  A site does not need to belong to a group, in which case the SiteGroup value is an empty string.  In the example, both Compaq.com and Exxon.com are members of the site group ‘group2’.

When the Ingeniux CMS Server begins to render the XML page,  it determines whether a given request is from a specific site or sitegroup and uses this information in determining how to further process the page. A site-specific entry has precedence over a sitegroup-specific entry so that a given site can use both site-specific and sitegroup-specific rules throughout the site to render the pages.

Rules for Dynamic Stylesheet Binding

In order to allow site or sitegroup-specific selection of stylesheets, the following rules are followed.  When a request comes in from a site, Ingeniux CMS Server determines whether there is a site mapping for the site.  If there is then it will look for the stylesheet, with the same name as the default one specified in the xml file, with the site-specific tag name appended.  For example, if the default style sheet is named story.xsl and there is a site entry for ‘compaq.com’ that maps to the tag name ‘compaq’, then Ingeniux CMS server would look for a style sheet named story-compaq.xsl and if it existed apply it instead of the default.

If there is no site mapping then Ingeniux CMS Server will look for a sitegroup mapping, and if it finds one it will look for the stylesheet named story-<sitegroup tagname>.xsl.  If there is neither a site nor sitegroup mapping, then Ingeniux CMS Server will look for the stylesheet with the default name, story.xsl.  For allowing different style sheets to be applied for different browsers, the rules would be the same as described above, except that it would look for the file in the appropriate directory.  For example, story-compaq-msie.xsl. 

This is the search order:

1. basename-<site>-<browser>.xsl
2. basename-<site>.xsl
3. basename-<sitegroup>-<browser>.xsl
4. basename-<sitegroup>.xsl
5. basename.xsl 

Site, Class, and Browser Attributes Available to all Stylesheets as XML Attributes

So that stylesheets can make decisions based on the site, class of site, or browser requesting a page, Ingeniux CMS Server adds the SITE, SITEGROUP, and USERAGENT elements to the IGX_Info section of the xml file.  If there is no mapping for a given request, then these elements will have an empty string value.  They will always be present.

To Learn More
To learn more about Ingeniux CMS please email info@ingeniux.com or call our Solutions Group at 206-788-4305.