A library of XML/XSLT functionality for execution in a browser, illustrated through demonstrations.
See the XSLT Blender Portal page for the demonstrations. There is a single portal (maintained in XML) and a library of scripts, with each demonstration adding its own capabilities and customizations.
This repository contains source code for both library and demonstrations, as well as project documentation. Projects will describe themselves both in demonstration and with their own README files.
Also see the project wiki for more detailed and extensive coverage.
This code base is intended to support development of lightweight client-side web applications exploiting the XML/XSLT capabilities currently offered as standard in browsers, starting with XSLT 1.0.
Developed originally for internal projects or for use at NIST, these projects are published here for the use of the public and by developers who can build on its foundations or study it as a model. Contribute to this project by offering positive commentary and constructive feedback (tell us what is working). New ideas for projects or feature requests will be considered and taken up based on the generality and acuteness of the need and the closeness of the use case. The repository is also designed to be improved on in your fork.
Elsewhere on line, impressive demonstrations of the current technology (XSLT 3.0) are available using the SaxonJS library from Saxonica. At NIST some of these capabilities have been shown in the context of the OSCAL project. XSLT Blender applications are not limited to OSCAL (though not exclusive of it either). At time of writing all the demonstrations on the site (and available through the portal page) use exclusively XSLT 1.0 as distributed with the browser (as a DOM Level 4 feature); that is, they run without any support from third-party libraries.
In general, applications here will process XML with XSLT. Depending on the application, the XML may be provided on the site, accessed from elsewhere on the Internet (when permissions obtain), or provided by the user. In most cases, the capability being demonstrated is implemented in XSLT, delivered by the server as a resource (asynchronously, in the background), and compiled and applied dynamically in your browser.
A noteworthy aspect of this arrangement is that if a file is provided by a user on their local system, it can be accessed and processed without exposure to any other application, service or point of contact. No file is uploaded to a server. No file, view or log is retained anywhere after the browser application is terminated. (A hosting page may do any of these things but the application itself will not.) Once the server has delivered a functional payload (host page and transformations specifications, aka stylesheets in XSLT), no data is passed across the network connection, instead residing entirely within the user's browser runtime, and disappearing with it.
In these demonstrations the stylesheets are applied by means of a library authored in Typescript and Javascript with as small a footprint as possible, for ease of use, deployment and maintenance. The intent is to make it easy to do things that should be easy, but that require some measure of engineering of pipelines and interfaces, which might be provided by such a library.
All source code, whether Typescript, Javascript or XSLT, is also available for inspection and testing. An isolated runtime (that is, download everything and run it off line) can help demonstrate the integrity of the application.
In the demonstrations, this code base can be exercised to show different kinds of functionality, including mixed applications where XSLT is used in conjunction with Javascript or with other Javascript (or Typescript) libraries supporting other functionalities, such as zipping/unzipping.
A particular area of interest is the pipelining of JSON data and integration of JSON data into XML-based pipelines, even using XSLT 1.0.
Use this repository by browsing the code base, trying the examples (as served in a plain web server or in the portal), then replicating and rewriting them.
Developers who are interested in this code base should consider both
- new applications showing new functionalities
- how you can contribute to building, extending and supporting this project or this approach
As work product of the National Institute for Standards and Technology (NIST), this software with its documentation is placed into the public domain, as noted in the License file, and is free for use provided that adequate notices of origin and modification are kept intact.
When you adapt this code please remove any NIST-identifying boilerplate text or branding from page views. While your site should retain appropriate credits, we cannot be responsible for misrepresentations and we expect you not to be.
A current statement of licensing applicable to this software appears here: https://www.nist.gov/open/license#software
Transcribed September 2022:
NIST-developed software is provided by NIST as a public service. You may use, copy, and distribute copies of the software in any medium, provided that you keep intact this entire notice. You may improve, modify, and create derivative works of the software or any portion of the software, and you may copy and distribute such modifications or works. Modified works should carry a notice stating that you changed the software and should note the date and nature of any such change. Please explicitly acknowledge the National Institute of Standards and Technology as the source of the software.
NIST-developed software is expressly provided "AS IS." NIST MAKES NO WARRANTY OF ANY KIND, EXPRESS, IMPLIED, IN FACT, OR ARISING BY OPERATION OF LAW, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, AND DATA ACCURACY. NIST NEITHER REPRESENTS NOR WARRANTS THAT THE OPERATION OF THE SOFTWARE WILL BE UNINTERRUPTED OR ERROR-FREE, OR THAT ANY DEFECTS WILL BE CORRECTED. NIST DOES NOT WARRANT OR MAKE ANY REPRESENTATIONS REGARDING THE USE OF THE SOFTWARE OR THE RESULTS THEREOF, INCLUDING BUT NOT LIMITED TO THE CORRECTNESS, ACCURACY, RELIABILITY, OR USEFULNESS OF THE SOFTWARE.
You are solely responsible for determining the appropriateness of using and distributing the software and you assume all risks associated with its use, including but not limited to the risks and costs of program errors, compliance with applicable laws, damage to or loss of data, programs or equipment, and the unavailability or interruption of operation. This software is not intended to be used in any situation where a failure could cause risk of injury or damage to property. The software developed by NIST employees is not subject to copyright protection within the United States.
Released in 1999, XSLT 1.0 remains an excellent language for data transformation tasks, including some that may surprise even today.
The language's grown-up version -- XSLT 3.0 -- is even more capable. But XSLT 1.0 has a peculiar advantage. Not unlike an AC power port in your car, you may not even know it is there, but it turns out to be useful and versatile.
We limit ourselves to XSLT 1.0 for several reasons:
- The viability for client-side XSLT 3.0 supporting applications -- more than one, considerably more ambitious -- is already being shown
- In contrast to other options, the actual capabilities of XSLT 1.0 have arguably never been widely understood (despite repeated demonstration), due in part to the immaturity until recently of Javascript support for resource handling in support of on-the-page XSLT infrastructure (e.g., asynchronous web and file system interaction)
- By delivering functionality, demonstrations can serve as useful and instructive examples for data processing systems in miniature - small models, open to emulation and study
- XSLT 1.0's limitations make it easier to deploy and use securely (see Testing along with wiki pages on Assessment and Controls)
Sticking with XSLT 1.0 for demonstrations, code bases can be small and relatively easy to audit. Vulnerabilities of the architecture, specifications and tools are well understood and preventable or mitigable. XSLT processors and their dependencies (such as parsers) have been well tested, and their degree of conformance with the relevant specifications is high.
XSLT 1.0 remains what it was in 1999, but the Internet has grown up around it, and Javascript (more precisely, ECMAScript) in particular is finally able to provide the level of support needed in web pages, to orchestrate transformations and interactions together. Using modern Javascript we are able to deploy asynchronous, defensible subroutines for acquiring resources and applying transformation logic flexibly, in a range of different scenarios, to achieve useful data processing operations in the browser, supporting display and interactivity.
Entire (albeit small and simple) applications can be written with no dependencies on external libraries. The basic capability that XSLT offers -- casting data from one descriptive format into another at arbitrary levels of granularity, while retaining structure and organization -- is simple, difficult to abuse or break, yet flexible in use, making XSLT applications well-suited to following the Rule of Least Power. When a code base is small, and the boundaries of its yard (its domain of capability) are well marked, there is less to go wrong. Hence the site tagline, "Least Power, Greatest Effect".
This also makes this project suitable for "weightless technology transfer" as described on the project wiki page.
This work is informed by daily and weekly practice with XSLT, and inspired by research by Will Thompson and Katherine Ford (as by XSLT practitioners everywhere):
- Ford, Katherine, and Will Thompson. “An Adventure with Client-Side XSLT to an Architecture for Building Bridges with Javascript.” Presented at Balisage: The Markup Conference 2018, Washington, DC, July 31 - August 3, 2018. In Proceedings of Balisage: The Markup Conference 2018. Balisage Series on Markup Technologies, vol. 21 (2018). https://doi.org/10.4242/BalisageVol21.Thompson01.
One of the projects has been presented at JATS-Con, the annual conference of the Journal Article Tag Suite (NISO JATS, ANSI/NISO Z39.96):
- Piez, Wendell. “A Generic STS Viewer on the Web”. Journal Article Tag Suite Conference (JATS-Con) Proceedings 2023. https://www.ncbi.nlm.nih.gov/books/n/jatscon23/piez/
CODEMETA.yamlCODEOWNERSCODE_OF_CONDUCT.mdCONTRIBUTORS.mdLICENSE.mdTESTING.mdfair-software.md
package-lock.jsonpackage.jsontsconfig.json
index.html
directory.xml
site/nist-boilerplate.csssite/nist-combined.css(copied from https://pages.nist.gov/nist-header-footer/css/)site/list-projects.xslsite/projects-html.csssite/projects-page.xsl
logos, graphics etc.
See directories
- JSON Mixer - can we do something (anything) with JSON in XSLT 1.0? yup
- STS Viewer
- OSCAL Styler
(... etc etc ...)
- Sources in
src - Compiled Typescript and Javascript goes into
lib - Additionally, projects may have their own Javascript libraries
- Miscelleneous files in
docs
README.md
The repository presents a set of web browser-based demonstrations, as embedded in (delivered by) a plain web site, with no back end or dynamic capability. They can be installed to run locally. Such an installation is also a testbed for development (below) inasmuch as the site administrator can easily modify, extend, add and replace applications or parts of applications.
When serving your derived XSLT Blender framework, take care to provide its exterior ("dress") with new design that distinguishes it as your work, especially removing all NIST- or distributor-related branding or indicators including (but not limited to) logos, headers and footers, font settings, theme colors and page links, replacing them with your own. License notices should retain acknowledgements of upstream contributors: you should not appropriate or "borrow" their (our) design, so changes to site-level CSS and hosting pages will be necessary for you to publish a clone in good faith, while proper credits are always acceptable. As the goal of XSLT Blender is to provide a platform for application development, such refurbishment can be considered a first step in local customization and extension. Congratulations and welcome.
For development and testing, and for additional assurance of data security, the demo site with all its applications can be served directly and viewed on localhost (see below) for "clean room" use, with no connection to the open Internet.
To install (globally) and then run a server in node js, for example:
$ npm install -g http-server
[... some good stuff ...]
$ http-server
This will start a web server on port 8080. Pointing your browser to localhost will load the demonstration site:
A page will show. XSLT Blender functionality can be confirmed by proceeding to load the directory and navigate.
XSLT Blender applications can also be served directly on the web, or pushed into a Github or Gitlab Pages site (such as what you might be reading), or other repository host, for wide availability.
XSLT Blender can also be integrated with static site generators like Jekyll and Hugo, combining the best and worst of multiple possible worlds.
For more guidance in this area please make inquiries.
Since these are client-side applications intended to be run in far-away environments, the development model relies on standards and simplicity to help ensure operations. Relevant standards -- XML, XSLT, CSS, occasionally others -- make it easy to do what would be hard, and possible to do what would be impossible.
A project will typically be built by:
- designing a conceptual model of a functional interface for XML/XSLT
- deploying a prototype coded by hand (HTML/Javascript) calling XSLT over XML sources
- iteratively develop the (XSLT) transformation along with with user interface
Over time, projects will show a range of different approaches and user interface capabilities, which can be borrowed, reused, and refined.
See the page on Architecture for a schematic of a typical project along with more information on project design.
By inspecting source code -- both statically and running in a demo -- an analyst should be able to determine the components of any given project. Demonstrations should be self-explanatory, assuming relevant background knowledge. Please do research or make inquiries!
- Declarative markup
- XML and XSLT
Scripting and application logic used in this site falls into four categories:
- The 'XSLT Blender' library (Typescript in
srccompiled intolib) provides generalized interfaces for XML and XSLT capabilities. - Per demonstration, XSLT provides the layering that gets content into the browser, typically via a 'cast' or mapping into HTML for a defined tag set or vocabulary.
- CSS applied to the page can then style this further - both CSS per demonstration, and site-wide CSS are used
- Javascript (lightweight, self-contained) may also be deployed to provide demonstrations with interactivity on the page
This describes the general pattern: in the case of individual demonstrations, it may be muddied or complicated by special requirements. For example, there may be more than one XSLT transformation, or none at all for a CSS-only project. A code base may be fairly large and complex, or quite small. A small code base may do useful things with large data sets. Etc.
To compile Typescript libraries from source, nodeJS and npm are assumed. But for many purposes this will not be necessary.
Designed to be delivered over the Internet using a browser, any application under development can be served locally, enabling a tight loop between code revision and execution. This in turn makes deployment easy, since once an installation runs on localhost, it needs only to be copied. All files to be served are *.html, *.js, *.css, *.xsl, and sometimes *.xml, and require only a plain generic web server configuration.
As noted above, with NPM, start a local server by opening a Linux/WSL prompt in the xslt-blender directory, and invoking npm serve, or simply http-server with that npm module installed.
Or run a vanilla web server using the http server of your choice.
Point your browser at index.html or the landing page of any demo, as served on localhost or the address of your server.
With a site up and running, XSLT can be tested directly in the application. You are likely to need a way to empty files from your cache or suppress caching.
XSLT can also be developed and tested in offline editing or coding environments, with representative sample inputs.
Applications are typically tested by development under load with representative sample documents, including representations of 'pathological' inputs.
See TESTING for more about testing and the kinds of testing performed. See the Assessment page on the wiki for information about second- and third-party assessment, both for functional testing and for security.
Note that XSLT applications (and declarative XML applications in general) are built in accordance with the security principle of "Least Power". As a domain-specific-language, XSLT is robust against hard failures entailing threats such as data exfiltration or denial of service. Unless you provide your own code to these code bases -- and even then, as long as you restrict your efforts to the transformation layer -- the worst they will be capable of will be "GIGO" (garbage-in-garbage-out) symptomized by incoherent layout, dropped contents or data "dumps" to your screen -- or in extreme cases (with stylesheets not properly tested), by suspending your browser.
By design, XSLT 1.0 is specifically limited. If as a developer you find yourself pushing the edges of its capabilities, consider using XSLT 3.0, a considerably more powerful language build on the same functional processing paradigm. More powerful capabilities come with broader security concerns, of course -- this is the principle of Least Power.
Mainly, Javascript can be developed on the page using the APIs, as demonstrated in numerous examples.
To maintain, modify or extend the library, edit and compile Typescript sources. This effort rewards itself in more maintainable project code, better code reuse, and more secure applications.
In the project subdirectory, enter npm install to install or reinstall the Typescript configuration.
Source code is in src. This is all Typescript compiled on NodeJS, so (with Typescript installed) enter tsc to produce Javascript runtime libraries, saved in lib and also open for inspection.
Note that applications have full access to XSLT without having to modify the libraries that are used to invoke transformations. Compiling the Typescript source (or writing, testing and deploying Javascript) is not necessary to code or extend any application, unless it goes beyond the transformation requirements ably addressed by XSLT.
npm installto install or reinstall the configuration (based onpackage.jsonandtsconfig.json)npm outdatedto check for outdated librariesnpm upgradeupgrades library componentstsccompiles everything insrc, writing tolib
Code here all runs in your browser with no runtime dependencies except as noted per demonstration. Particular demonstrations may carry license information as required (see their respective readmes).
This project is maintained by Wendell Piez, NIST ITL/CSD (Information Technology Laboratory, Computer Security Division), Secure Systems and Applications Group. Please contact w e n d e l l (dot) p i e z (at) n i s t (dot) g o v.
Additionally please feel free to open or respond to Issues in this Github repository or to contact the developer in public forums.
Piez, Wendell (2022), XSLT Blender, US National Institute of Standards and Technology (NIST), https://doi.org/10.18434/mds2-2813.