Balisage Paper: Interactive web applications: demonstrating SaxonJS

Old promise, new realization

XSLT was originally designed with client-side processing in mind

This never / quite happened or did it? with XSLT 1.0

Impediments to this effort

At long last, Saxonica offers a solution that addresses both problems

Background / context / problem: (lack of) business case for exposing XML (what?)

The web is dead

Several things killed it, including the predominant advertising-based sustainability model

The web is a big competition over placement and ranking in indexes

Bots and crawlers are more important than people, as "consumers"

Much information has retreated again behind pay walls

So hasn't XML in the browser missed its moment?

But the browser has emerged as a platform

Nevertheless the web subsists / evolves / matures as a capable medium because there must always be a "reductio" ("base") medium to which other media / channels can appeal

Thus it remains a way to get stuff in front of people

(One at a time if not en masse)

Meanwhile it has become more standard and stable with cross-browser scripting and CSS a priority

Opportunity of the moment

An XSLT processor capable of arbitrary transforms can be compiled and run under Javascript (who'da thunk it)

In the case of SaxonJS, the transformations (XSLT) must be compiled up front

Saxonica offers this feature under Saxon PE and EE licenses

Once XSLT is compiled, further use / sharing is free (no costs, licenses or registration for anyone)

Drop it onto a web server and go

Why this may actually work

SaxonJS is carefully placed on the strategic fine edge between standards-based and proprietary

As a proprietary platform it externalizes everything it can to the standards

This creates new possibilities of "information arbitrage" - power of XML at lower cost - to them that hath, shall be given

SaxonJS is licensed but your XML, XSLT, compiled SEF and design all belong to you

External dependency on http server + Javascript-capable browser(s) is – sustainable?

What about the business case

It's still difficult to argue for "giving away the semantics"

Yet - while XML can expose the source, with SaxonJS we get obfuscation of the processing, for free

(Yes, we can still obfuscate the source if we want to)

This places stress on XSLT (compiled into SEF) as (site of) "added value": not the information but its rendition (logic)

For some kinds of applications this might actually work

How it changes design

Emphasis goes back to the work as a whole, no longer so much "pages"

Multiple views and access points reflect peculiar semantics of the source data

Server doesn't disappear, just becomes a resource

Question: How about XForms under SaxonJS? (XRX with SaxonJS in front)

There is no irony here

SaxonJS is deployed in Javascript so we don't have to write Javascript

XSLT turns out to be really good at event handling!

XML publication becomes its own archive

(Edit XML in git repo, then render via XSLT/SaxonJS?)

What kinds of data, again?

Product documentation

Standards, reference catalogs and authority files

Educational or not-for-profit publication

Public domain, government and open data sets

Half-empty part

Architecture is still a bit opaque and cumbersome

You still gotta know XSLT (boy do you)

Development and debugging

Getting started kit

See github.com/wendellpiez/XMLjellysandwich

Set of stylesheets can produce:

Demonstrations

New ways to learn XSLT