Program

CEM-ML is a declarative document lifecycle engine for structured content. It reads sources such as CEM-ML, CSV, JSON, YAML, CSS, and the HTML/XML family into typed, source-map-bearing AST/event streams; validates them against schema-package contracts; and then converts, transforms, formats, colors, or renders them through the same pipeline.

The project has two authoring layers. The core runtime is written in Rust and builds as a Linux-native CLI and as WebAssembly for browser hosts. The domain contracts are declarative: schemas, package manifests, formatter/colorizer resources, and transform templates are authored as CEM-ML and CEMT package assets rather than hard-coded as format-pair shortcuts.

For command-line users, cem-ml provides validation, conversion, transform graph execution, reports, terminal output, and HTML/SVG previews. For browser users, the same engine exposes an async WASM API used by Declarative Custom Element (<custom-element>) and the planned <cem-element> substrate, so declarative components can parse data, run transformations, and render light DOM without moving the document semantics into handwritten JavaScript.

The author has started to design and work with an object-oriented class system for XQuery.

Limited experience3 so far suggests a tension between thinking about an application document-first and object-first.

Object-oriented markup can shield the developer from changes in markup, and even from the markup itself, but in that case, why bother?

The answer is a synergy that combines both views, and declarative object-oriented XQuery supports such a view.

The talk will present the object oriented class system both from a developer/query-writer point of view and from an implementer’s perspective, and then discuss the implications.

The presentation argues that declarative languages are structurally better suited in an age where AI generates software.

It will point out which factors contribute to that potential strength, touching on formal semantics and structural schema information, and how documentation and curated examples help compete with imperative coding that builds on a much wider base of training data.

The argument will be made using Fore as an example, and which steps were taken to train AI on delivering accurate results.

Finally, there will be a comparison between React and Fore, with early results on time-to-solution, token usage, and accuracy of solution, and what those numbers suggest so far.

The EXPath project (previously known as EXSLT 2.0) and its website (expath.org) was originally forked from the EXQuery project (exquery.org). EXPath is best known for publishing community standards that define the behaviour of a number of XPath extension functions. These functions may then be implemented by vendors or perhaps even users, and made available in various XPDL (XPath Derived Language - e.g. XQuery, XSLT, XProc, XSpec, XForms, and XPath) implementations.

Unfortunately the EXPath project has languished in recent years, and until June of this year (2026) the standards provided on its website have been unavailable to read for more than two years. During this time several enquiries directed to the founder of the EXPath project who retains control of the expath.org website have remained unanswered. Whilst this was a welcome and much appreciated resource provided to the XML community at no-cost, it can sadly no longer be depended upon.

As the founders of the EXQuery project, one of the custodians of the EXPath GitHub organisation, and previous contributors to the EXPath project, we have taken it upon ourselves to try and reboot the EXPath project.

Our first goal, is to secure and modernise a website for the EXPath project. The biggest complaint we have heard about EXPath in recent years is that the standards published on its website were no longer readable. To that end, we have secured expath.xyz domain name. Furthermore, the EXPath standards were previously authored in EXPath Spec markup, itself a derivative of the XML Spec markup used by the W3C. Using XSLT we have converted these to the more modern ReSpec HTML5 Markup standard used by W3C. We have designed a new simple website for expath.xyz and created CI jobs that triggers and publishes the newer ReSpec standards there when they are updated in their Git repository.

Our secondary goal, which is not yet complete, is to continue with our previous work from 2015 of trying to develop common interfaces for EXPath Modules, so that common implementations of each EXPath standard may be written and published once, but deployed on many vendors implementations.

XForms provides a declarative approach to developing web applications by separating user interface, data, validation, and business logic. This paper presents the latest developments in Saxon-Forms, an implementation of the XForms 1.1 specification that executes entirely within the browser using interactive XSLT 3.0 powered by Saxon-JS.

Building on our previous work, we describe the major architectural changes and implementation milestones that have brought Saxon-Forms close to full conformance with the XForms 1.1 specification. We also discuss the continued relevance of XForms for XML-centric applications and demonstrate how Saxon-Forms integrates with technologies such as XSLT, XPath, and XProc to support modern declarative application development.

XQueryX is a recommendation for an XML notation of XQuery. It is directly inspired by the XQuery EBNF grammar but with convenient differences for following evaluation. XQueryX is used in homemade XSLTForms XPath parser but this parser has its own limitations.

XQuery is text, XQueryX is XML: is it a good idea to use Invisible XML to generate XQueryX from XQuery?

Invisible XML grammars are context free and are always detecting ambiguities which can be problematic for performance for big inputs.

Different topics are to be considered:

• Ambiguities in XQuery EBNF grammar
• Ambiguities in XQueryX XML schema
• Whitespace troubles
• Limitations of a context free parser for a programming language
• Proposed extensions for Invisible XML engines
• Postprocessing on resulting XML nodes

Grammix is an Invisible XML Javascript implementation which has been extended for XQueryX generation.

The proposed extended Invisible XML grammar for XQueryX allows to parse XQuery 3.1 sources. It supports all XQuery 3.1 features with minimal restrictions for whitespaces. Its conformance has been evaluated against XQuery 3.1 Test Suite.

This presentation will report on a project that started as the simple setup for an XML-native workflow for the Greek Tax Authority. As the project evolved, the requirements and complexity grew exponentially. The sources for migration went from 3000 Microsoft Word documents to 15000 documents stemming from various sources, including scanned pages in polytonic Greek. Customizing the authoring environment to the project's needs, turned out to be so complex that both input and output required special tuning.

In this process flexibility became crucial. And with flexibility quality assessment became an important part of the project's workflow. It would be too easy to make this presentation a complaint about how fast things can go sour in a project. However, the presentation will rather focus on solutions and opportunities found in the process.

The heart of the XML-native workflow consists of some XProc3 pipelines. The application of XProc in this project eventually turned out to be the enabler of the required flexibility. This presentation will present some background and some techniques on the use of XProc in this project and where it was found to be particularly useful.

This talk presents a perspective on ambiguity in invisible XML which differs from the common approach of finding strategies to eliminate or mitigate ambiguity in grammar writing.

To begin, I will give a general overview of ambiguity, situating the topic in the context of formal language theory. I will show how ambiguity is treated by some popular parsing algorithms, and explain why it can be a problem for parsers in terms of speed and efficiency. I will then consider some of the more common types of ambiguity encountered by users of iXML, briefly outlining some popular strategies for managing such cases.

Having established this foundation, the main body of the talk will consider situations in which ambiguity may be either unproblematic or actually desirable. I will suggest some methods by which ambiguous results may be made more useful without the sometimes considerable frustration of trying to remove all ambiguities from a grammar.

The talk will encourage iXML users to experiment with ambiguity and to write useful iXML grammars with confidence.

We built an ixml implementation in Rust from scratch. Designed as separate reusable core and CLI packages, this implementation focused on user experience, clear diagnostics and good documentation. Beyond parsing and serialisation, we implemented modularisation, round-tripping, the experimental not and subtraction constructs and developed a static HTML conformance suite viewer. In this presentation, we will share our experiences, design choices, and lessons learned. We will compare support for features beyond ixml 1.0, and present measurements of speed and memory use against other ixml implementations.

A few years ago, a cheeky grad student at one of my undergraduate presentations characterized structured authoring and OASIS DITA in particular to be a "dinosaur dance party." Her argument was that the once-prominent DITA evangelists were all retiring, companies seemed less willing to make long-term investments in content, and XML structure had all but vanished from college course offerings. If the world were moving toward more disposable or more AI-generated content, what was the point of teaching undergraduates concepts and/or best practices for structured authoring?

Her observations are partially correct – and we need to address those concerns.

I chair a committee in ACM SIGDOC that is focused on three things:

• Understanding current obstacles to instructors teaching structured authoring.
• Providing no-cost content and consulting that instructors can use to jump-start courses on structured authoring.
• Building industry/academic partnerships in support of teaching structured content.

Our ACM SIGDOC charter is at: https://sigdoc.acm.org/structuredauthoring/
Our Committee resource library is at: https://acm-sigdoc-structured.org/1-curriculum-resources.html
We have learned that the fundamental concepts and best practices associated with structured authoring can be separated (in large part) from implementation technologies, e.g. DocBook, DITA, MS Word, Google Docs, et al..

This seems congruent with the theme of this conference, focusing on the "what" of a program more than than the "how."

LMNL tagging permits overlap; accordingly, models using LMNL as a basis can describe multiple concurring hierarchies (MCH). While LMNL ranges do not make hierarchies, they can be mapped straightforwardly to structures that do, including XML.

Equally, since no hierarchies are imposed, LMNL documents and document processing can be tolerant, in ways XML cannot, of inconsistent and experimental tagging, while also being subject to querying, testing and validation whenever appropriate and helpful. Hierarchy is apparent, but not inevitable – in other words, it becomes significant, among and with other patterns and regularities.

This makes LMNL an attractive vehicle for exploratory markup, that is, markup prior to the definition of a formal model and in preparation for it: tagging for discovery.

This project presents a version of Homer's Iliad provided with LMNL markup in an open source repository built using public datasets (PerseusDL) and open-stack XML-based tools (XProc, iXML, XSLT). Data description is declarative and informed by TEI (among others), but free-form and heterogeneous, so its regularities emerge from the text.

Projects to be presented:

https://github.com/wendellpiez/Laminator/
https://github.com/wendellpiez/EpicMarkup/

XForms is a declarative programming language for writing applications for the web and elsewhere.

One of the strengths of the language is how data is described: types, constraints, and relationships between values declaratively describe the structure, validity, and interconnection of data, as global properties.

A central part of this is invariants that describe relationships between values, such that if a value changes or is changed, its related values specified in the invariants get updated automatically. This is much like how spreadsheets work, though more general. A major advantage of this approach is that much administrative detail is taken out of the hands of the programmer, and left to the computer: the programmer specifies the relationships, the computer does the work.

Sorting data is one of the major tasks of many programs, and this is usually done programmatically: the data is, or becomes, unsorted, and a function is then called to order the data suitably.

On the other hand, being sorted is often just a necessary property of the data for the rest of the program to function properly, which could just be stated declaratively, leaving the work to ensure it remain sorted to the computer.

This paper discusses the issues involved, and how the question was approached when adding declarative sorting to XForms, as well as touching on implementation details and advantages.

During Balisage 2026 the author demonstrated a browser-based application, implemented in ~XSLT4, SaxonJS, SVG and limited Javascript code, using XML data, which involved significant audio and graphic components.

[Sneak preview - a player piano]
These required sub-second co-ordination to keep audio and graphics in reasonable sync, as well as meeting near-real-time progress.

The design methodology was to build as much as possible at a high level in XSLT to get the application running and overall functionality decided and then tune the time-sensitive performance aspects by progressively ‘compiling’ the data streams into more fundamental, and less expensive structures.

This paper will look in detail at how this design progressed and suggest some lessons for the development of similar applications.

When building interactive features on a webpage, JavaScript is usually the way to go. However, with great JavaScript dependencies comes great website instability. Even a minor undefined element can cause your entire webpage to crash.

That’s where going back to the basics comes in. Thanks to modern Web APIs, it’s now possible to reduce JavaScript dependency on a website by swapping out JS components for their native HTML element or CSS feature counterparts.

In this talk, we’ll take a look at how to use HTML and CSS to build simpler alternatives to popular JavaScript components such as accordions, modals, scroll transitions, carousels etc We’ll also take a look at the performance and accessibility benefits and real-life applications and use-cases of these components.