Program

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.