Vignette company presented the first commercial solution of CMS (Content Management System) class in 1995. Since then the number of commercial CMSs is diligently growing up and the CMS term settled down on the market. Many of open standards have been approved lately. They allow to structure information within sites, separate it from design, but the most of CMSs still don't follow them. The XSLT standard exists for quite a long time. It allows to form documents from different sources: XML-files with structured document contents and an XSL-template with the description how the document will be presented at the site. Besides, document forming can be performed at the client side. You need only to assign the address of a data XML-structure with the link to an XSL-template to a browser and the browser will draw the page in that way as designers supposed. Usually the content of each page is different, but the form of delivery is limited with only few templates. Therefore, XSLT allows reuse once written code repeatedly. Well, it seems to be a perfect technology for CMS. However, a set of factors restrains mass using of the technology. Site functionality definition XSLT is a hard task. Moreover, an XSL-template too much depends on an XML-document. It limits flexibility of the solutions based on this technology.
So, XSLT is a perfect solution in conception, but practically too laborious. This causes developers to find new solutions, that include features of the open standards and are easy to use. One of those solutions is XML Sapiens markup language.
How is XML Sapiens arranged?
XML Sapiens supposes every document within project is bound with a template. The template can contain presentation code (for example, HTML) and XML Sapiens constructions. The template can include some files. It can be reached by means of sapi:include instruction, which is near to the analog in the xInclude open standard
<sapi:include href="file_template_address" parse="template" ></sapi:include>
Other XML Sapiens instructions allow to deliver content and functional blocks to a document.
The aim of the solution is to separate the description of content structures and the description of functionality. This allows to create a set of content structure layouts and a set of functionality layouts only once and use it as a kit within site development.
XML Sapiens and data
XML Sapiens has such notion as interface state. It allows to define for a site page different sets of data in according with external or internal conditions. Assume that a user is authorized on the site. The page will contain one set of fields. If he is not authorized, it will contain another set. Field set states of a content page is defined in an XML?document. You need use sapi:include instruction with a specified state to apply a filed set.
<sapi:include href="file_template_address" parse="fieldset" state="a2" ></sapi:include>
A field set contains data delivery instructions. These instructions bind a specified data identifier with a filed type, which is described in the external XML-document.
<sapi:apply name="qc.identirier.value" type="type" href="type_description_address" ></sapi:apply>
XML document of a field type also can contain type descriptions for different interface states. If we have defined ?administrating? and ?content delivery? states, we will see the data within a content query form in the first case, and the data ?as is? in second case.
XML Sapiens and functionality
A page template can contain instructions of a functionality scenario request. Algorithm of the scenario is described in a specified XML-file.
<sapi:apply name="ddc.menu.value" href="scenario_address" ></sapi:apply>
A document of functionality algorithm description (DDC) contains instructions of conditions analysis. Syntax of DDC also allows to point to a CMS-application, which, in according with assigned parameters, return data streams for next condition analysis.
<sapi version="2.0" xmlns:sapi="http://www.xmlsapiens.org/spec/sapi.dtd"> <sapi:ddc name="sample"> <sapi:choose> <sapi:when exp="eq(this_record_id.value,0)"> <sapi:for-each select="cms_application()" name="enum"> <sapi:params> <sapi:param name="param1">value1</sapi:param> <sapi:param name="param2">value2</sapi:param> </sapi:params> <sapi:ifempty>Records not found</sapi:ifempty> <sapi:fallback>CMS-application error</sapi:fallback> <sapi:choose> <sapi:when exp="gt(this.this.a_variable_from_data_stream.value,0)"> <sapi:code> Sample code, &this.this.a_variable_from_data_stream.value; </sapi:code> </sapi:when> </sapi:choose> </sapi:when> </sapi:choose> </sapi:ddc> </sapi>
It is allowable to point request parameters within a functional scenario. It allow reusing of functional scenarios.
<sapi:apply name="ddc.menu.value" href="http://site.com/ddc/menu.xml"> <sapi:param name="param1">value1</sapi:param> <sapi:param name="param2">value2</sapi:param> </sapi:apply>
As you see, XML Sapiens allows to prepare a set of data structure descriptions, a content field type set, functionality and use all of them within site designing. Reusing of those components reduces costs of web-development and lets to avoid low-level programming. XML Sapiens is a universal language. You can use it in a CMS, which is based on any programming language.
The language exists more than 2 years and, recently, the version 2.0 has been published. It gives the hope language will develop and be used. At the moment there are only a few XML Sapiens-based CMS. But if this number increases, exchange of independent web-application functionality will become a standard.