Patterns and antipatterns in micropipelining within XSLT

The program logic of pipelining is often expressed by nesting function calls within one another. An alternative formulation assigns intermediate results to a number of convenience variables. But in XSLT, legibility can break down in a sea of parentheses, and maintenance is a challenge when both variables and references need to change or be reordered as you add, delete, or rearrange steps in the pipeline. We can avoid these challenges by expressing the pipeline as a sequence of simple steps (for example, operations in a visitor pattern or a table of matching value pairs for string replacement). Single steps are easier to read and also easier to edit because adjustments to a step are self-contained and do not affect other steps.

An XSLT Translator for the openEHR Archetype Definition Language

The cityEHR Electronic Health Records system is a pure XML application for managing patient health records, using open standards. The structure of the health record follows the definition in the ISO 13606 standard, which is used in cityEHR as a basis for clinicians to develop specific information models for the patient data they gather for clinical and research purposes. In cityEHR these models are represented as OWL/XML ontologies. The most widely adopted approach to modelling patient data in accordance with ISO 13606 is openEHR, which uses its own Archetype Definition Language to specify the information models used in compliant health records systems. This paper describes a translator for the Archetype Definition Language, implemented using XSLT and XML pipeline processing, which generates OWL/XML suitable for use in cityEHR.

XML Applications on the Web

How can we use XML, XQuery, and SCXML (State Chart XML) to implement the Model component in a Model-View-Controller web application? First we must be able to do function decomposition of XQuery functions that perform updates (a task rendered more complex by XQuery's restrictions on updating expressions). Then we would like a systematic method of using UML state diagrams in the design of the web application and of integrating an SCXML processor into the implementation of the Model component. A BaseX extension implementing the WebSockets protocol enables us to make the Model observable and thus to realize multi-player games that require server push. All these practices are compatible with domain-driven design and model-driven solutions; they pave the way for XML developers to create XML-based applications on the web.

Compiling XSLT3, in the browser, in itself

This paper describes the development of a compiler for XSLT3.0 which can run directly in modern browsers. It exploits a virtual machine written in JavaScript, Saxon-JS, which interprets an execution plan for an XSLT transform, consuming source documents and interpolating the results into the displayed web page. Ordinarily these execution plans (Stylesheet Export File, SEF), which are written in XML, are generated offline by the Java-based Saxon-EE product. Saxon-JS has been extended to handle dynamic XPath evaluation, by adding an XPath parser and a compiler from the XPath parse tree to SEF. By constructing an XSLT transform that consumes an XSLT stylesheet and creates an appropriate SEF, exploiting this XPath compiler, we have managed to construct an in-browser compiler for XSLT3.0 with high levels of standards compilance. This opens the way to support both dynamic transforms, in-browser stylesheet construction and execution and a potential route to language-portable XSLT compiler technologies.

Making a difference by processing JSON as XML

Anyone who has ever published more than one version of a document can readily understand the benefits of tracking changes within it. Systems and APIs that exchange JSON haven’t typically been able to take advantage of such tracking, though the problems of changing JSON structures are essentially the same as in XML. This paper looks beyond JSON Patch (a fine specification as far as it goes) to a more general mechanism for representing changes in JSON, one that includes the context of the changes so that new ways of processing change can be supported. Along the way, it introduces a loss-less, bi-directional transformation from JSON to XML, making the more mature XML processing infrastructure available to JSON developers. The best of both worlds.

It's more than just overlap: Text As Graph

The XML tree paradigm has several well-known limitations for document modeling and processing. Some of these have received a lot of attention (especially overlap), and some have received less (e.g., discontinuity, simultaneity, transposition, white space as crypto-overlap). Many of these have work-arounds, also well known, but—as is implicit in the term “work-around”—these work-arounds have disadvantages. Because they get the job done, however, and because XML has a large user community with diverse levels of technological expertise, it is difficult to overcome inertia and move to a technology that might offer a more comprehensive fit with the full range of document structures with which researchers need to interact both intellectually and programmatically. A high-level analysis of why XML has the limitations it has can enable us to explore how an alternative model of Text as Graph (TAG) might address these types of structures and tasks in a more natural and idiomatic way than is available within an XML paradigm.

Using DITA to Create Security Configuration Checklists

Many software tools use security configuration checklists expressed in the Extensible Configuration Checklist Description Format (XCCDF) to monitor computers and other information technology products for compliance with security policies. But XCCDF syntax is checklist author-unfriendly. And complex relationships and dependencies between and among checklist rules, checking instructions, and software platforms make it difficult to reuse or repurpose existing XCCDF content in new checklists. The Darwin Information Typing Architecture (DITA) can tame XCCDF syntax and facilitate content management and reuse. A case study comparing the use of specialization and other DITA features with a currently-deployed ad hoc XCCDF authoring system demonstrates the advantages of the DITA approach.

The Concrete Syntax of Documents: Purpose and Variety

In the mid-eighties a group at Stanford built the MUIR language-development environment as a system for notation design with rendering and layout from the abstract syntax, parsing from concrete syntax, and semi-automated transformation between language variants. We developed models for representing documents at all levels and understanding how the levels relate to one another. Presentation widgets have a purpose: to convey specific abstract syntax relationships. Having an account of what kinds of widgets there are, what kinds of abstract relationships there are, and how the two connect allows for an analysis of how the notation works as a whole. The concept of "notation" taken here is a broad one, encompassing programming or technical notations as well as the form of structured documents of various kinds. Notation designers can apply such an analysis to improve their designs so that the structure is more clearly conveyed by the concrete syntax or so that humans can more readily use the notation without confusion. Software can render or parse instances of notations using rules that capture the concrete syntax, the abstract syntax, and the rules between them in a declarative.

Life, the Universe, and CSS Tests

The W3C CSS Working Group maintains a CSS test suite already composed of more than 17,000 tests and growing constantly. Tracking the results of running such a large number of tests on a PDF formatter is more than anyone could or should want to do by hand. The system needs to track when a test’s result changes so that the changes can be verified and the test’s status updated. Finding differences is not the same as checking correctness. An in-house system for running the tests and tracking their results has been implemented as an eXist-db app. Is it a masterpiece of agile development, or an example of creeping featurism?

SOCRview: a case study of RESTful web application development for publishing

SOCRview is a RESTful HTTP service layer that exposes content--including transformed, packaged, listed or analyzed content--to other services, programmers writing ad hoc scripts and users through persistent, readable, meaningful and concise URI. Lessons learned from the first proof-of-concept allowed expansion to include customization layers for commonly used delivery formats.