NOTE: This is a restored version from this archive.

Introduction

XSLT can be used to transform XML data in various ways. An application often seen is to use XSLT to transform XML data for presentation, building HTML / XHTML / WML / whatever documents. This allows for a clean separation between domain-specific data documents following a dedicated schema, and a presentation-dedicated markup language. This way, data documents can be produced and used by other tools that don’t need to care about presentation issues.

Separation between data and presentation is a well known strategy, but it requires programming skills, building or using frameworks that are language-dependent if not platform dependent. XSLT itself is a platform independent language, but to implement a model/view framework using XML and XSLT, you have to write down some real code, even if it is only to select and load the proper stylesheet and run the XSLT engine (in the simplest frameworks).

Even if I have programming skills and the required experience, as the webmaster of an ISP-hosted small web site, I cannot expect to deploy those frameworks on my ISP’s shared hosts. Low-cost shared hosts barely provide anything else than FTP access. And even if I found a cooperating ISP (which is “only” a matter of money, anyway), I would have to stick with him and would not be able to promptly switch to another ISP without migrating the whole project, reconfiguring servers, giving away more money and so on.

Yet, we could expect that given a simple enough specification, it would be possible to have a simple and consistent model/view framework, that could be implemented in any language and run on any kind of platform.

That’s the purpose of this programming idea. Such a framework would enable a lot of people to benefit from model/view separation, just by editing XML and XSLT files, while using low cost shared hosts, without having to care about the technology running it. Those people would then only edit their XML content, being able to change their site look or prepare device-specific renderings of their sites in a breeze.

Objectives

The objectives of this framework are :

• to provide a simple mechanism by which static XML data files can be server-side transformed according to stylesheets carefully selected amongst a set of available stylesheets
• to be implementable in any XML-enabled server-side technology, especially in Java, ASP, ASP.NET, Perl, PHP, Python, C and C++.
• to be usable on low-cost shared hosts, in a context where only FTP access to the host is allowed. Of course, the HTTP server on the host must have a mechanism to run the framework (servlets, ASP, ASP.NET, CGI-Bin, PHP, etc.), but this mechanism only needs to be configured once, by the ISP.
• to make sure that a site using the framework can be deployed anywhere the framework is supported, independently of the underlying technology, just by copying its files. There should be no need of tweaking the HTTP server, the servlet engine, PHP module configuration or whatever.
• to have a true model/view separation, with the capability of switching views depending of various parameters.
• to operate without requiring the site author to write code for a controller. This would imply selecting a programming language, thus breaking the portability objectives. Like a static HTML site can be browsed without any page-specific server-side controller (all pages are served the same way by the HTTP server), no page-specific server logic should be needed. This is why I write model/view only and not the usual model/view/controller (MVC).
• if any code has to be written by the author, it must be written in XSL/T. Yes, XSL/T is severely limited as a programming language, but is it supported my most XML toolboxes, in various languages.

Binding a view to a model

The Limits of <?xml-stylesheet?>

A basic approach of the model/view problem with XML technologies is simply to put some data (the model) in an XML document, some presentation instructions (the view) in an XSLT stylesheet, and bind the two by mentioning the stylesheet URI in an xml-stylesheet processing instruction, like mentioning in this W3C TR.

A framework based on this is easily implemented. It is already implemented on the client-side by some web browsers (such as Microsoft Internet Explorer). It would be easy to implement on server-side, no matter the technology, language or platform used. We could say that we rely on this simple mechanism and stop there.

Going further

However, while this kind of binding ensures that data and presentation are formally separated, so that one part can be modified without touching the other, it severely restricts the power of the model/view separation. Indeed, this kind binding prevents a model from having different views.

Ideally, the selection of a view to apply to a model depends on various criteria, either static or dynamic :

• the type of data represented by the model : a recipe is not rendered the same way as a bill.
• the context of access : some information can be filtered out depending on the interest of the user.
• security considerations : for example, some part of the model cannot be seen by anybody except a few users (those who paid for, for example).
• the terminal used to access the data : web browsers accept HTML or XHTML documents, WAP browsers accepts WML documents, voice services require a VoiceXML rendering, and so on.
• the desired rendering : users could ask for a printer-friendly rendering, an SVG rendering to import into their favorite slideshow program, etc.

Some of those criteria can’t be found in the model itself. In fact, only the data type can be determined from the model. The other criteria are dynamic, depending on the terminal used to access the data, the mood of the user, its security profile and so on.

Therefore, embedding a processing instruction mentioning the XSLT stylesheet (view) within the XML data document (model) is not an option. We must design a way to bind a model to a view that takes into account the dynamic criteria.

Model type and view types

To keep the framework simple, we will base the view selection on three criteria only :

• model type : identifies the type of data found in the document
• logical view type : identifies a particular logical view of the same model type. Different view types match different functional objectives.
• physical view type : identifies a particular physical view of the same model type. Different view types match different presentation languages.

Thus, whereas the xml-stylesheet instruction bound one and only one view to any given document (model instance), this framework defines the notion of model type which can have many associated view types. This way, the same document can be rendered in many ways (many logical views) or many presentation languages (many physical views).

Why is there a separation between logical and physical view types ? [TBA : is there really a difference ? ]

Identifying the model type

How does the framework find the model type of a given XML document ? [TBD: do we use the DOCTYPE ? Root element name ? A PI ?]

Hyperlinking model instances

Some kind of hyperlink rewriting must be performed to ensure that the view types are correctly propagated through hyperlinks. This should be done with clever XSLT templates and stylesheet parameters. [TBD]

Implementation ideas

• On-disk caching of the result of XSLT transformation would greatly improve performances.
• The final site could be offline rendered against a particular physical view type, in case the framework cannot be installed on a host.