Program

The document world is experiencing an ice age, a descent into tribalism and chaos, as the ideas behind declarative markup are forgotten and a leap has been made from What You See Is All You Get word processors and (worse) page layout software into the now-ubiquitous README.md markdown format, in which what you see is less than what you get and not at all what you need.

In twenty years, in ten years, next week some time, will the ideas behind declarative markup be forgotten? If so, who will keep the iron wheels turning in the mineshafts of technology?

What must we record, write down, vlog, so that people who come after us can keep the system working, let alone make new systems?

Nelumbo is a new language designed for declarative language development and logic programming. With Nelumbo, you can define the syntax and semantics of your language, and immediately parse, test, and execute your definitions. Nelumbo offers declarative semantics and good performance. Inference results include complete or incomplete sets of proven facts and/or falsehoods. Therefore it is able to support all logical operators in a intuitive manner. Nelumbo is open source and you are invited to participate in its development. Nelumbo is developed based on extensive experiences in the formalization of (tax) law, (clinical) knowledge and more. Wim will give a live demo and discuss the rationale behind Nelumbo's creation.

In this talk, I introduce the Amsterdam Theorem Exchange: a distributed proof assistant where users on the network are able to submit formal mathematical conjectures together with a price, and – when the price is right – the system returns either with a proof or a counter-example. Also there are solvers on the network that seek valuable but outstanding mathematical problems, trying to tackle them by using human and artificial intelligence. This talk explains how and what formal methods are needed to implement this system, that subnets specialize to solve different classes of problems, and argues that the Amsterdam Theorem Exchange is more valuable than all cryptocurrency systems combined – since problems include e.g. prime factoring problems and problems of reversing cryptographic functions.

RumbleDB is a scalable, open-source engine for querying large-scale semi-structured data using JSONiq on Apache Spark. Building on previous contributions by David-Marian Buzatu and Marco Schöb, we have continued the shared effort to extend RumbleDB with initial support for XQuery 3.1, enabling distributed declarative processing of massive collections of XML documents. This new capability allows users from the XML ecosystem to leverage the power of Spark without abandoning familiar declarative patterns.

Our implementation covers a wide range of XQuery 3.1 features, including FLWOR expressions, node constructors and comparisons, built-in functions, arithmetic, and more. As a result, we now pass over 50% of the 32,000+ test cases in the official QT3 Test Suite, marking a major step toward full compliance. We also integrate community-driven proposals for the XQuery Scripting Extension and JSONiq Updating Expressions, further enriching querying capabilities of RumbleDB.

This work has significantly increased the compatibility of RumbleDB with existing XQuery-based applications. By bridging the gap between the XML world and modern distributed systems for the Big Data era, we hope to foster wider adoption of RumbleDB and grow an open, collaborative community around scalable declarative data processing.

In our publishing office, we have developed an XML vocabulary for describing automated parts of the workflow, called MIRA. A MIRA project contains one or more tasks, which each contain one or more actions. Projects use database data and/or user selected options to generate and execute automated workflow steps. 

Reading the XML project file can sometimes be somewhat cumbersome. Therefore we looked for ways to provice additional documentation for the projects and after some pilots with hand-created workflow diagrams we set out to generate these from the XML projects in order to keep the documentation in sync with the evolution of the various  (hundreds of) project files. 

With just a few extra attributes and a separate transformation stylesheet, we have been able to generate diagrams out of the project files, using the Mermaid diagramming tool showcased two years ago at Declarative Amsterdam. This use case serves as a nice example of how the declarative nature of the XML documents and Mermaid can work together.

Following the important May 2025 announcement in Germany by ZB MED of OLSPub - the Open Life Science publication database - there now exists an open, reliable, and sustainable alternative to the US-based PubMed database of biomedical research publication metadata:
https://www.zbmed.de/en/research/current-projects/olspub
The GitHub repository then was created by Réalta Online Publishing Services Ltd. as a set of simple tools to assist OLSPub users of PubMed metadata XML files. These tools recognize that having to deal with raw XML markup can be discomfiting to those allergic to angle brackets:
https://github.com/RealtaOnline/PubNote?tab=readme-ov-file#readme

An important property of the rendering tools in this package is the off-the-shelf running implementation of sustainable single-source publishing practices. This sustainability concept was introduced at JATS-Con 2023 in contrast (in the author's opinion) to traditional relatively unsustainable single-source publishing practices. OLSPub users can trigger human-oriented visualizations of PubMed XML metadata in PDF, HTML, and DOCX syntax for their review in their favourite tools.

This presentation first introduces the new OLSPub resource and how it services the life sciences research community.  The suite of simple tools is described, illustrating the results available to users.

Sustainable single source XML publishing is reviewed, and the open-source tools supplied in the repository that implement sustainable single source publishing are enumerated and demonstrated.

My history lies with JavaScript with about 14 years of experience. I rolled into the XQuery world later on, building an Open Source XPath 3.1 / XQuery 3.1 processor in TypeScript before I wrote my first line of XQuery. Nowadays most of the code I’m writing in XPath or XQuery. A significant part of that is maintaining existing codebases.

I miss some of the ergonomy of developing in JavaScript. Any mature JS project includes prettier: an automatic code formatter. XQuery has no automatic formatter. XQdoc defines a styleguide, but manually applying codestyle makes no one apply it. XQLint comes with a formatter, but it does not format everything.

Introducing prettier-plugin-xquery: a plugin to Prettier that formats XQuery. Supporting XQuery 3.1 but extensible to format the other extensions and dialects, like the update node syntax in eXist-db,XQuery update facility, the Marklogic extensions and more.

The presentation will highlight the following subjects:

• Using the rex parser generator for parsing XQuery and its dialects,
• Merging multiple grammars to make a grammar for XQuery and all its dialects
• Using the plugin to format XPath in XSLT
• How to use this plugin in your daily development!

Since Roaster was released in January of 2021 it has gained some traction within the eXist-db community. Because of the paradigm shift naturally this was adopted first by new projects, like tuttle and jinks.

 But there is interest to migrate existing applications to this new model, as it has proven itself in production.

In this talk I will

• highlight the possibilities and benefits of a design-first approach when designing APIs
• present the issues we faced and the learnings we got out of solving them developing Roaster for several years
• show an entirely new tool OAD which is also the basis for the new direction the project is heading

JSONPATH is a query language from 2007 that has become a proposed IETF standard as of February 2024, RFC9535. As seen at XML Prague 2024, JSONPATH is not quite as general as XPATH, but it benefits from broad adoption in the industry and more than fifty (50) different implementations. The major parts of an implementation of JSONPATH are: a) parsing the input query via the grammar, which is described in ABNF in RFC9535 b) generating the "selector" expressions from the input query that will "select" the results of the query evaluation c) traversing the query input values and applying the selectors to produce the output. Part a) is handily managed via invisible XML, providing an AST description of the input query. Part b) uses the generated AST to compose functions, including functions that issue from partial function application, providing an example of the utility of XPath's higher order function capabilities. Part c) can be implemented in an elegant manner that highlights the expressiveness of XPath. The intention is to provide both a reasonable, conformant JSONPATH implementation and also to showcase the expressiveness of XPath combined with Invisible XML.

Invisible XML enables producing an XML document from a text value according to a grammar, which specifies rules for generating elements and attributes.

In certain use cases, round-tripping is required: unparsing the resulting XML document back into text.

Three steps are proposed for this unparsing:

• Grammar normalization by pruning meaningless rules and symbols.
• Inversion of the normalized grammar
• Parsing of the XML document with the inverted normalized grammar

Grammix is a Javascript implementation for parsing text values and unparsing XML documents according to an Invisible XML grammar. Grammix internally uses an Earley parser.

Invisible XML makes the implicit structure of textual documents explicit by parsing, and then transforming the resultant parse-tree into an abstract document. This abstract document is the essence of Invisible XML: it can be processed in many ways, though principally by serialising to XML.

However, as shown in an earlier paper on roundtripping ixml, it is possible to simultaneously simplify and generalise the ixml serialisation process, thereby opening it to other serialisations that are not hard-wired in the processor. By the same token, this further simplifies ixml proper, by reducing it to a simple transformation of grammars from ixml to an equivalent Invisible Markup grammar.

This paper investigates the changes needed to create an Invisible Markup Language, investigates the alternatives, and proposes future steps.

In this talk, we’ll take the concept of declarative programming and apply it to designing for the web.

Instead of focusing on controlling the outputs of the design process, we’ll look at creating the right inputs instead. Leave the final calculations for the outputs to the browser – that’s what computers are good at. We’ll look at CSS features, design systems, design principles, and more.