XML Summer School
XML Summer SchoolBMT logo

Web 2.0 with XML
24 September 2009

Bodleian Library

Turning the browser into a work station

C. M. Sperberg-McQueen
Black Mesa Technologies LLC


The Web pushes content out from servers onto users' desktops. How much of the processing can we push out to the browser with it? Can we make our Web applications distributed not just in terms of the geographic spread of the users but in terms of the CPU load? The more work we can perform in the user~s machine, the less work must be done by the central server(s), and the less dependent the application is on network latency. Three technologies can help.
First, data transformation in XSLT can run in the browser, instead of on the server, if we can work around the occasional gap in the existing browser implementations of XSLT. Second, Javascript can be used as a relatively simple glue to manage XSLT transformations in the browser. Cross-browser libraries make this easier than it would otherwise be. Third, XForms can be used to turn the browser into an XML editor specialized for a particular vocabulary and task, with sophisticated user-side validation of input and cross-field constraints.

Turning the browser into a workstation

Why bother?

Why bother? Revisited

Well, no. It's not that simple.
  • You still have to validate. (Why?)
  • Asynchronous requests are still requests.
But ...
  • How many adversaries?
  • How many well-meaning errors?
  • You may still save cycles.
  • User experience still better.

Didn't they give up on that idea?

Lots of pundits on the Web will explain:
  • XML was intended to be shipped to the client.
  • XSLT in the client is a failure.
  • It cannot ever work.
  • You can't use it even if it works.
  • You shouldn't use it even if you can.
  • XML was never intended to be shipped to the client and parsed there.
  • It belongs on the server.

They're confused about some details.

Or maybe they just don't know what they're talking about.

The goals of XML

The goals of XML include:
  • Reusability of data.
  • Self-determination by authors and publishers.
  • Freedom of ontology.
  • Ability to deliver on the Web using descriptive markup.
Universal adoption by users happy with HTML was never a requirement or a goal (even if many involved felt it would be a good thing).

Other preliminaries

XSLT in the browser

Current support for XSLT in the browser

Virtually all current browsers include XSLT processors:
  • Internet Explorer
  • Mozilla
  • Firefox
  • Opera
  • Safari

Some sites that deliver in XML today

Making it work

The basic tool: the XML stylesheet processing instruction.
N.B. No alternate stylesheets, no cascades.

Some practical tips

Some pitfalls and limitations

To work across all browsers, keep to intersection of their XSLT support:
  • document() missing in Opera
  • namespace::* missing in Firefox
  • unparsed-entity-uri() missing or buggy in some browsers
  • xsl:output method="xml" (often used to produce XHTML) displays formatted in Safari and Opera, unformatted in Firefox (and IE?). So grit your teeth and use xsl:output method="html".

Working locally, working on the Web

A practical issue.
Ideally, you want to
  1. edit locally
  2. display locally
  3. upload to server without changing anything
  4. display on the Web
Two approaches (at least):
  • parallel structures
  • ghost stylesheets
XML Catalogs not helpful (browsers don't support them).

Parallel structures (1)

  1. Does same server serve all
    • XML documents
    • XSL and CSS stylesheets
    • DTDs and other ancillary files
  2. Do you have r/w access to the server?
  • Mirror (the relevant parts) of your server locally, with the same directory structure.
  • Use relative references for all stylesheets, DTDs, etc.
  • Working locally, relative references point to file-system copies.
  • Working on the Web, relative references point to server-side copies.

Parallel structures (2)

  PUBLIC '-//C. M. Sperberg-McQueen//DTD
          TEI Lite 1.0 plus SWeb (XML)//EN'
          '../../../lib/swebxml.dtd' >
<?xml-stylesheet type="text/xsl" 
  <!--* ... *-->

Ghost stylesheets (1)

If parallel structures aren't feasible
  • e.g. multiple sites involved
  • e.g. collaborators don't want to mirror your site
then ...

Ghost stylesheets (2)

... then
  • On client
    • Make a ./lib subdirectory everywhere* you have XML instances.
    • Use a symbolic link to a single master copy.
    • Collaborators can just copy the data.
  • In the document
    • Refer to stylesheets and DTD in ./lib subdirectory.
  • On the server
    • Redirect all references to .../lib/foo.xsl to standard location.
      • Using HTTP redirect (preferable).
      • Using server-side rewrite or other tricks (if necessary).

Ghost stylesheets (3)

  PUBLIC '-//C. M. Sperberg-McQueen//DTD
          TEI Lite 1.0 plus SWeb (XML)//EN'
          'lib/swebxml.dtd' >
<?xml-stylesheet type="text/xsl" 
  <!--* ... *-->

An example

Just a little Javascript

N.B. not an introduction to Javascript or to Ajax libraries.

What you need

The stylesheet PI works fine, for single stylesheets.
But to
  • offer choices
  • pass parameters to stylesheet
  • invoke when choose
  • invoke on ancillary documents
you want to invoke the processors in the browser.

Basic functions

We need to:
  • load arbitrary document into DOM
  • load arbitrary stylesheet into DOM
  • invoke arbitrary stylesheet on arbitrary data
  • display result as whole document
  • display result as partial document

Getting what you need

The native Javascript is not hard.
But an off-the-shelf library is better.
With Sarissa, it's easy to implement functions to do what you need:
  • DomFromXmluri(uri) → DOM-instance
  • DomFromXmlstring(string) → DOM-instance
  • DomFromTransformXmlXslt(iDOM,xslDOM) → DOM-instance
  • DomFromTransformXmlXsltParams(iDOM,xslDOM,parametres) → DOM-instance



XForms background

Why XForms?

What's wrong with HTML forms?
Micah Dubinko, co-editor of the XForms spec, says:
  • Poor integration with XML
  • Limited features make even common tasks dependent on scripting
  • Device dependent, running well only on desktop browsers
  • Blending of purpose and presentation
  • Limited accessibility features

XForms and M / V / C

XForms used model / view / controller pattern.
  • model: digital representation of reality
  • view: user interface exposing (part or all of) model
  • controller: intermediary between model and view
In the case of XForms:
  • model: one or more XML documents
  • view: XHTML page with XForms widgets, CSS styling, etc.
  • controller: binding of widgets to elements and attributes

Padded cell editors

  • In large projects, work is often layered / staged.
  • In each layer, focus on one task.
  • ... so focus on one operation.
  • Full XML editors support many operations.
  • So full XML editors are dangerous (as well as hard to learn).
  • What we need are safer editors. Lots of them.
  • As a consequence, we need quicker ways to develop highly specialized editors.
XForms is essentially a technology for developing padded-cell editors.

XForms examples

XForms widgets (1)

XForms resemble HTML forms:
  • text input
  • textarea
  • invisible-text
  • file uploads
  • select one from list
  • select several from list
  • submit

XForms widgets (2)

XForms differ from HTML forms:
  • new output widget
  • range
  • relevant control
  • no hidden widget
  • the reset widget intentionally made harder
  • richer submit: multiple submission possibilities from same data

XForms ‘control flow’

Purely declarative. Well, mostly declarative.
  • relevance:
    • xf:bind can specify conditional relevance of an item.
    • Irrelevant widgets are not shown.
    • Irrelevant elements, attributes are not submitted.
  • switch and case elements:
    • Turns blocks of the view on and off en bloc.
    • Allows user control of navigation in multi-part forms.

Declarative forms

Without scripting, we get:
  • basic datatype validation
  • range checking
  • in-page calculations
  • in-page references to forms data
  • nested groups of fields
  • repeating groups of fields
  • adding or deleting items or groups of items

A simple example

<h:html xmlns:h="http://www.w3.org/1999/xhtml"
        xmlns:x="http://www.w3.org/2002/xforms" >
  <h:title>Search form</h:title>
   <x:submission id="s" method="put"
    action="file:///home/cmsmcq/2003/talks/xforms/output.data.xml" />
  <h:h1>Search form</h:h1>
  <h:p><x:input ref="q"><x:label>Find</x:label></x:input></h:p>
  <h:p><x:submit submission="s"><x:label>Go</x:label></x:submit></h:p>

XForms deployment

Ideal world: intrinsic support in browsers.
For now: ...

XForms deployment 1: server-side

The server does most or all of the work:

XForms deployment 2: in the browser

XForms 3: stand-alone

Stand-alone and embedded:
  • OpenOffice
  • Lotus Forms
  • X-Smiles (Helsinki Univ. of Technology) XML browser in Java, runs both stand-alone and embedded; can also run in browser as applet


The browser is more than a terminal.
It can understand XML.
It can style XML under user control.
It can easily become a special-purpose editor.

Thank you

Thank you.