Program

Saxon-Forms is a (currently) partial XForms implementation developed using Saxon-JS, an XSLT 3.0 run-time written purely in JavaScript. Designed for browsers the mechanics of the XForms implementation such as actions are implemented using ‘interactive’ XSLT 3.0 extensions available with Saxon-JS, to update form data in the (X)HTML page, and handle user input using event handling templates.

NCL is the declarative programming language used to develop TV applications in IPTV systems and Terrestrial TV standardized by ITU[1] and Brazilian TV Forum, respectively. Its main characteristics are support: defining temporal synchronization among media assets and viewer interactions; layout reuse facilities (<region> and <description>); support multi-device presentation; scripts in the light-weight and embeddable language Lua; and an API for building and modifying applications on-the-fly called NCL editing command. This talk briefly introduces NCL, highlights its recent advances and discuss the future of the language.

We introduce Rumble, a query execution engine for large, heterogeneous, and nested collections of JSON objects built on top of Apache Spark. While data sets of this type are more and more wide-spread, most existing tools are built around a tabular data model, creating an impedance mismatch for both the engine and the query interface. In contrast, Rumble uses JSONiq, a standardized language specifically designed for querying JSON documents. The key challenge in the design and implementation of Rumble is mapping the recursive structure of JSON documents and JSONiq queries onto Spark's execution primitives based on tabular data frames. Our solution is to translate a JSONiq expression into a tree of iterators that dynamically switch between local and distributed execution modes depending on the nesting level. By overcoming the impedance mismatch in the engine, Rumble frees the user from solving the same problem for every single query, thus increasing their productivity considerably. As we show in extensive experiments, Rumble is able to scale to large and complex data sets in the terabyte range with a similar or better performance than other engines. The results also illustrate that Codd's concept of data independence makes as much sense for heterogeneous, nested data sets as it does on highly structured tables.

Abbreviations used in this presentation:

CLI: Command-Line Interface
CSV: Comma-Separated Values
DAG: Directed Acyclic Graph (a graph with no directed cycles, also known as dependency graph)
ETL: Extract-Transform-Load, to import data in a database
FLWOR: for-let-where-orderby-return (pronounced as 'flower')
HDFS: Hadoop Distributed File System, it is an open-source framework for storing very large datasets on a cluster.
HTTP: Hypertext Transfer Protocol, the basis of the Web
JSON: JavaScript Object Notation
RDD: Resilient Distributed Dataset, Spark's data primitive
ROOT: CERN's native format for high-energy physics data.
S3: Simple Storage Service, Amazon's cloud storage service
SQL: Structured english Query Language
UDF: User-Defined Function

XML Resolvers are a core extension feature in XML parsers and other applications in the XML stack. They allow you to transparently satisfy requests for DTDs, schemas, stylesheet modules, etc., with local copies of those resources. This offers improvements in both performance and security. XML Resolver 3.0, available in Java and (soon!) C#, provides full support for the XML Catalogs standard and a broad range of features designed to make deploying and using catalog-based resolution faster and easier. This talk will highlight the new features of the resolver including:

• Dynamic catalog construction with caching.
• Automatically loading catalogs from extension modules (jar files or assemblies).
• Improved support for resources distributed in extension modules. 
• Handling http: and https: entries transparently. 
• Validation of catalog files. 
• Namespace-based resource discovery by indirection through RDDL documents.

Declarative approach to routing requests in eXist-db

Audio software, and particularly digital signal processing, is an application domain where the imperative, object oriented programming model dominates. In part, this can be justified by the realtime constraints that underly the domain, and that C/C++ has historically dominated the high performance native software landscape. But this is not without cost: the high barrier to entry prevents developers from trying to write audio software, and the industry spends far more time than needed to deliver new products. 

In this talk, we'll look at some of the complications that come from writing low level native audio software in C/C++ with an imperative, object oriented model. Then we'll reframe the conversation to show why a functional, declarative approach may be fundamentally more fitting for the problems we want to tackle when writing new audio software.

Finally, I'll introduce Elementary Audio: a new JavaScript runtime for writing realtime, native audio applications with a functional, declarative API. We'll see how Elementary applies the declarative model to audio software, and then finish with a detailed example of a small drum synthesis library written in Elementary.

'Invisible XML' ('ixml') is a method for treating non-XML information as if it were XML; it was proposed by Steven Pemberton in 2013. The basic idea is straightforward: a context-free grammar is used to describe the structure of the information, annotations in the grammar specify how the raw parse tree of a sentence in the language described by the grammar is to be represented into XML, and an ixml parser uses the grammar to parse the non-XML document into an XML form. This allows all the tools of the XML toolbox to be applied to the data: XQuery and XSLT for general processing, XForms for creating user interfaces to the data, XML schema languages for validation, and so on.

Aparecium is an ixml parser written in XQuery and XSLT, as a library of functions callable from XQuery and XSLT. (The name is a reference to a spell in the Harry Potter novels, which makes invisible writing visible.) When used to parse external resources, Aparecium can be thought of as a replacement for the standard doc() function which can read non-XML data and deliver it as XML; it can also be used to parse strings which obey a context-free grammar, such as CSS style specifications, XSLT pattern expressions, SVG path expressions, and so on. The latter makes Aparecium useful for handling XML formats which use micro-grammars for some portions of documents.

For simplicity, Aparecium is implemented as a pipeline of processes. First the extended BNF notation allowed in ixml grammars is translated to an equivalent unextended BNF. This grammar is then used by an Earley parser to parse the input; the result is a large set of 'Earley items' describing various aspects of the parse. From the set of Earley items, Aparecium then constructs a 'parse-forest grammar' describing the set of parse trees in the input. As a final step, a parse tree is extracted from the parse-forest grammar and returned to the caller. Alternate interfaces may be used to specify that the parse-forest grammar should be returned, instead; this may be helpful in cases of ambiguity, since it allows the caller to study the ambiguity and in some cases to extract the preferred parse tree.

In some cases the caller will have the grammar in the non-XML form described in the ixml specification; in others, the grammar will be available as an XML document; sometimes the caller will have a URI for the grammar. The input may similarly be available either as a string or as a URI. Aparecium provides distinct calls for each of these situations, to simplify the use of Aparecium in constructing applications.

The talk will briefly describe the current status of Aparecium implementation and (the gods willing) show a simple demo; it will conclude with a discussion of some next steps in the work on Aparecium and in the development of broader support for invisible XML.

Despite its many warts and wrinkles, SQL is undeniably a declarative success story. Teaching declarative thinking is often impeded by the procedural mindset of students originating from their early training almost exclusively in imperative programming languages. While SQL databases are optimized for executing SQL, students tend to write inefficient and clumsy code using disputable so-called “procedural extensions”. A few typical examples will be presented. While a limited kind of declarative constraints are supported in SQL, implementations generally fall short of the potential of database-wide declarative constraints. Some notions are illustrated by looking at declarative referential integrity, triggers as a poor substitute and an experimental RDBMS called “Rel”. As a concluding impulse for discussion, the presumed waste of talented declarative minds by the overpowering imperative bias in teaching is addressed.

Günter Burgstaller teaches “Database and Information Systems” at the HTBLuVA Wiener Neustadt’s informatics department since 2009. Austria’s unique technical college system, recognised in the EU as third-level education, trains students from 14 years on to become highly-demanded engineers in the course of five years. Graduates are also eligible for university.
Prior to teaching, Günter Burgstaller worked for 15 years as a database and systems engineer in various IT companies.

The vision for a semantic web is over 20 years old, yet so little of our internet is currently using linked data. Where did it go wrong, and what can we do to revive this dream? Atomic Data is a modular specification that aims to make the semantic web achievable again through a developer-friendly ecosystem of tools that enable high data interoperability and return ownership back to the user.

The Extensible Markup language (XML) provides a way to share information with tagging specific to content domains, rhetorical forms, or other needs. By contrast, HTML markup is evolved synergistically with Web browsers in mind, and the tagging is largely specific to browsers. Although EPUB was (is) based on XML, it's also based on HTML: it uses XHTML for the documents. As a result, there is little to no support for domain-specific markup, and the ebook experience seems unimaginative, constrained by the intersection of Web browsing and content silos. What might happen if there could be communities evolving domain-specific markup for electronic texts? For 3D models or live mathematics, for poetry, for music and musical scores inside books? For context-specific dictionaries and glossaries, for per-chapter tables of contents and wayfinding cards, and so much more. Is there any way to enrich ebook readers in this direction?

Over the last few years, “Tools for thought” has become a hot concept among software makers. We’ve seeing a surge in note-taking apps and knowledge management tools presenting themselves as TFTs. But there’s a strange paradox here: taken at face value, the phrase “tool for thought” doesn’t have the word ‘software’, ‘computer’ or ‘digital’ anywhere in it. It sounds like an idea that belongs to philosophy and cognitive science department, rather than computing. How and when did it become intertwined with computers? What are we to make of all the software upstarts identifying with this movement? And how can we push beyond them into a new generation of computational tools for thought?

A brief overview of current developments in XForms.

In lexicography, dictionary entries are usually encoded in XML. Typically, lexicographic XML contains a high degree of purely structural markup: elements whose only purpose is to group other elements together instead of marking up human-readable text. This makes XML-encoded dictionary entries verbose and complex. In this talk, I will explain why this is. Most lexicographic content, such as definitions, example sentences and translation equivalents, is inherently ‘headed’ and would most economically be represented as a triple (name + value + children), whereas in XML every element is a tuple (name + value and/or children). This means that a single content item cannot be represented with just one XML element, leading to purely structural markup. I will review strategies that are common in lexicography for dealing with this problem in XML and in other data languages such as JSON and YAML. I will conclude that not a single one of these popular languages serves the needs of lexicography well because neither has good support for representing headed triples. The only languages that do are XML’s historical predecessor SGML (thanks to its mark-up minimization features) and a less well-known language called NVH which was specifically designed for that.

In 2012 a Packaging System specification was developed by the EXPath project for use with applications written in XML - EXPath Pkg. There is very little about Pkg that is XML specific, for the most part it just defines a container and some metadata.

Implementations of this specification emerged for eXist-db, Saxon, and Marklogic. For the most part it appears that the standard never really caught on, apart from the eXist-db implementation to the best of our knowledge there are no other implementations of Pkg still in-use. The specification itself was both incomplete, and lacking in detail. The resulting implementations, including the one for eXist-db, were therefore unsurprisingly rather unsatisfactory to say the least. They lacked many features, and offered many bugs. Major shortcomings include: a lack of sufficient ability to express dependencies between packages, a lack of dependency resolution, and a lack of suitable public/private repositories of dependencies. There have also been other efforts in the XML space both before and after EXPath Pkg to create a satisfactory packaging system, but likewise these don't seem to have had much uptake. Of course, we must acknowledge that building a single new Packaging System from scratch is no small feat, and by extension writing a complete specification to describe the semantics and mechanics of such a system so that others may create interoperable implementations is a task of herculean proportions.

In this paper we look at what a replacement for the EXPath Pkg specification might look like, and how it could alternatively perhaps be implemented through reuse rather than reinvention.

The XSLT Extensions Community Group, known informally as “QT4CG”, has been working on new editions of XPath, XQuery, XSLT, and related specifications for just over a year. This presentation will provide a brief survey of how much progress we’ve made, how much more we might imagine remains to be done, and some of the exciting new functionality that will be available in “4.0”.

I will demonstrate how the XSD Visualizer Plugin supports the way XML Schema is understood and utilized. By providing an intuitive interface and interactive features, even newcomers to XSD can grasp its complexities with ease. The presentation will cover key concepts of XML Schema, demonstrate the plugin’s functionalities, and showcase real-world examples to highlight its practical applications.

Whether you’re a seasoned XML Schema expert or just starting to explore the domain-specific language, this presentation will leave you with valuable insights and a newfound appreciation for the visualization of data structures. As a bonus, I will also discuss the expansion to other format like Relax NG and JSON Schema.

Diagrams are an important part of the specification and documentation of software or other technological and societal artefacts. Many types of diagrams have been used, from flowcharts in the 1920’s, to Nassi-Shneiderman diagrams, UML, Entity Relation Diagrams, and C4 ion the 2010’s. There are a plethora of diagramming tools available, most of which provide a boxes-and-lines graphical user interface to draw diagrams.

In this presentation we focus on text-based diagramming tools, specifically Mermaid. Tools like Mermaid have the advantage of being declarative; The user specifies what is in the diagram, not how this will be graphically represented. In this way, making diagrams becomes quicker, diagrams can be more easily modified, and can be processed by software.

We will look at some diagram types and how to specify them in Mermaid. There are several tools available to transform Mermaid syntax into graphical output, both on-line and off-line, and we will see how to use these.

With Mermaid, diagrams become a powerful tool for software analysis, providing insights that are hard to get from code in a visual way. We will show an example of this, debugging and optimising a web component by generating a diagram for the function call graph.

Conversely, it is possible to generate code from diagrams. We intend to show an example of this as well. Depending on whether the singularity has already happened in November, we will see how a LLM can generate Mermaid diagrams.

One of the main developments for the next major release of SaxonJS is a redesign of the mechanisms for asynchronous processing from XSLT. The new conceptual design, and implementation, is closely aligned with JavaScript promises, making it more accessible to users familiar with the JavaScript processing model. A new extension instruction ixsl:promise can be used in the place of the existing instruction ixsl:schedule-action to initiate an asynchronous process, and specify its handling on completion or failure. A number of new extension functions are provided to create promises (e.g. for asynchronous resource fetches and HTTP requests), and to enable these to be chained and processed concurrently. In this presentation we will provide an introduction to IXSL promises with examples and demonstrations in anticipation of the release of SaxonJS 3.

In the upcoming Environment Act due in parliament later this year, a methodology for assessing the biodiversity of a site and its improvement will be enshrined in UK planning law. The detailed calculations are embedded in an Excel spreadsheet of some complexity. Although spreadsheets (excluding macros) are arguably declarative, they presents some problems for the ease of comprehension of the calculations, traceability to supporting documents and validation.

This presentation will outline the problem, look at an alternative declarative implementation using an executable conceptual model written in XML with XQuery formula interpreted by an XQuery application running on eXist-db and consider some of the issues of software-defined legislation.

Further details on the current state of the project.

ixml is a declarative language for transforming data representations, which became a stable specification in 2022.

The original pilot implementation of ixml, ixampl, was written in the very-high-level programming language, ABC, the forerunner of Python.

The implementation is split into two parts: a bootstrap parser, that reads ixml grammars and transforms them into the structure needed for part 2, which is a generic parser that reads any document and transforms it into XML. Part 1 is about 700 lines of code, part two about 780.

One of the many possible uses of ixml is to transform any data representation into XML so that it can be used as input to XForms, a Turing-complete declarative programming language that uses XML as its data format. To illustrate this, a code browser was made for the ixampl implementation, in a nicely self-referential way, using a 30 line ixml grammar to transform the ABC code into an XML representation, and use this as input to an XForms application of around 120 lines that enables you to browse and search in the ixampl code. Although the browser is for ABC code, with the exception of the ixml grammar there is little that is specific to ABC, meaning that it would be easy to adapt it for another language.

So combining two declarative technologies, we were able to create a useful, functional code browser in only 150 lines of code.

In this live coding session we will see, how Swift's versatile type system can be used to create compilable codes resembling declarative markup. We will create sophisticated data structures together, that encodes a book model, and see, how we can render them in the user interface.

L-systems, or Lindenmayer-Systems, are a way to describe natural growth patterns as well as a fun mathematical applications.

After introducing different types of grammars (deterministic, stochastic, parametric) and how they work we will show implementation strategies, various experiments and different applications such as to create visualizations with a process resembling Turtle Graphics.

Prolog was invented by A. Colmerauer for processing natural languaged, and  formalized by R. Kowalksi as SLD resolution on Definite Horn clauses in 1972.

It was touted as the “original” declarative language: Just “declare” your knowledge as Horn clauses in FOL to describe relations, and Prolog inference will automatically answer queries to those relations.

But, it’s not always (often?) so easy. In general, there are problems with:

• loops (incompleteness),
• performance,
• negative knowledge,
• weak numeric inferencing, 
• etc.

Each problem detracts from Prolog’s declarativity; they must be addressed by the user using more procedural thinking, turning the “declarer” into a “programmer.” But over the 50 years, each of these issues have been addressed (not “solved”).

In this talk I will focus on how Prolog has been extended with “tabling” to address the issue of incompleteness (looping), how that leads to interest in a specialization of the Prolog language to the language of Datalog, how Datalog generalizes SQL view definitions with inductive definitions. I’ll show some applications of Datalog. I’ll also describe how the improved completeness provided by tabling contributes to a better understanding and implementation of negation.

If there is time, I will discuss the elegance and importance of meta-programming in Prolog.

XSLT is designed on the use of compile-time declarative techniques. These oblige the stylesheet writer to declare a-priori what the XSLT processor assembles into a state machine. This machine reflexively acts on data according to an expected vocabulary that is pushed at the stylesheet. Designed with features such as declared attribute sets and named templates that are helpful when producing XSL-FO, there are requirements in the real world needing more flexibility than such provides.

NISO STS XML is an XML vocabulary used by multiple Standards Development Organizations (SDOs), each expecting a particular formatted result. National Bodies (NBs) publishing adoptions using XML need to publish the amalgam use of the NISO STS XML of their own and that obtained separately from different SDOs, while preserving each NB's and SDO's appearance for their data found in the result document.

This technical presentation is a case study of useful declarative techniques using applied templates in a novel manner and using tunnel parameters allowing a core reusable stylesheet library to create different XSL-FO effects in a single XSL-FO result produced by a single execution of an XSLT stylesheet.

The early conferences put on by FORCE11, the Future of Research Communications and e-Scholarship, were exciting events.  FORCE11 was founded because kindred spirits around the world felt that our current system for scholarly publishing seemed to be stuck in a model that had come into existence 350 years ago.  The early conferences were originally named “Beyond the PDF” exactly for that reason. While most of our revolutionary zeal was directed towards pushing new forms of communication and reward systems for designed around data and code sharing, these conferences also shined a spotlight on how even seemingly mundane processes such as formatting needed to be rethought.  

After the 2013 Beyond the PDF meeting in Amsterdam, I wrote a little blog about the costs imposed by simply porting conventions about formatting from the print era into the electronic age on scientific productivity (and the author’s blood pressure!).  In this presentation, I will revisit the issues raised in the blog to see where we stand and perhaps bring up other petty annoyances that are eminently fixable.