Conference Programme

This session introduces the Schematron Users Meetup, which focuses on the Schematron language for validating XML documents. The session is designed to provide an introduction to Schematron for those unfamiliar with it, as well as offer updates on the current state of the Schematron standard and software. The meetup covers various topics including the origins and benefits of Schematron, an overview of implementations and available tools, updates on the ISO Schematron standard, and lightning talks by Schematron users demonstrating their use cases. The session concludes with a general discussion on Schematron and its applications.

This session introduces the Schematron Users Meetup, which focuses on the Schematron language for validating XML documents. The session is designed to provide an introduction to Schematron for those unfamiliar with it, as well as offer updates on the current state of the Schematron standard and software. The meetup covers various topics including the origins and benefits of Schematron, an overview of implementations and available tools, updates on the ISO Schematron standard, and lightning talks by Schematron users demonstrating their use cases. The session concludes with a general discussion on Schematron and its applications.

The XProc editorial committee (Norman Walsh, Achim Berndzen, Gerrit Imsieke, Erik Siegel) would like to organize an XProc Users meeting at the Markup UK pre-conference.

It's been a while since we had such a meeting and we think it would be a good idea to get together again. Talk about the recent developments (3.1, XML Calabash 3, etc.), exchange war stories, discuss the future, etc.

The XProc editorial committee (Norman Walsh, Achim Berndzen, Gerrit Imsieke, Erik Siegel) would like to organize an XProc Users meeting at the Markup UK pre-conference.

It's been a while since we had such a meeting and we think it would be a good idea to get together again. Talk about the recent developments (3.1, XML Calabash 3, etc.), exchange war stories, discuss the future, etc.

XForms is an XML-based, Turing-complete declarative programming language for applications both on and off the web.

Experience with both small and large applications has shown that programming in XForms can reduce the time and resources needed for programming to a tenth or less of what is needed using traditional procedural programming.

This tutorial introduces techniques and idioms used in XForms for putting its facilities to best use. Each section of the presentation is followed by an exercise where attendees apply the technique themselves by editing an existing example.

This is an updated and revised version of a tutorial given earlier, based on experience teaching it.

While it would be beneficial to have followed the earlier "Introduction to XForms" tutorial, available online at http://cwi.nl/~steven/xforms/tutorial/, it should still be possible to follow this tutorial without it.

The tutorial is a hands-on, bring your own device tutorial; attendees will be required to install a small piece of software (a server that accepts the PUT method). The materials will be available online for self-study after the conference.

XForms is an XML-based, Turing-complete declarative programming language for applications both on and off the web.

Experience with both small and large applications has shown that programming in XForms can reduce the time and resources needed for programming to a tenth or less of what is needed using traditional procedural programming.

This tutorial introduces techniques and idioms used in XForms for putting its facilities to best use. Each section of the presentation is followed by an exercise where attendees apply the technique themselves by editing an existing example.

This is an updated and revised version of a tutorial given earlier, based on experience teaching it.

While it would be beneficial to have followed the earlier "Introduction to XForms" tutorial, available online at http://cwi.nl/~steven/xforms/tutorial/, it should still be possible to follow this tutorial without it.

The tutorial is a hands-on, bring your own device tutorial; attendees will be required to install a small piece of software (a server that accepts the PUT method). The materials will be available online for self-study after the conference.

Producing formatted pages is still important to many of us. The intent of the Antenna House pre-conference session will be to again share developments and experiences in producing paged media and to discuss topics of interest.

This Pre-Conference Day session will be a session of two halves: we’ll talk with you about the state of Antenna House software, including what’s new with Antenna House Formatter V7.4, and you can talk with us and with your peers about challenges that you’ve faced or features that you’d like to see.

Once again, this is an opportunity to brainstorm with the assembled about a challenge you’re facing and are trying to solve.

Generating pages from XML, no matter which tool you use, is typically a batch process using preconfigured stylesheets, so we are particularly interested to hear how you tweak individual documents to correct bad page breaks, keep a figure with its text, and so on.

If you have an interesting example to share, please get in touch with Tony Graham.

We want this session to address what you are interested in. Give us your comments!

2025 is a big year for accessibility: the European Accessibility Act (EAA), which comes into force on 28 June 2025, covers potentially every electronic version of a book that becomes available in Europe after that date. As well as EEA, there's EN 301 549, WCAG, Section 508, the Equality Act, ISO 30071-1, PDF/UA, and other standards to think about.

This session will discuss the accessibility landscape, with particular reference to the EAA and the other standards to which it refers. It will also look at what you need to put into your XML to be able to get accessible output as well as aspects of styling the output to make it more accessible.

This will not be one-way information exchange: there will be time in the session for you to discuss what has worked, or not worked, for you when making XML documents accessible.

Most current ixml grammars are small. However there are examples of large grammars, and it is likely that in the future more large grammars will emerge as ixml usage increases.

To make large grammars more manageable, and to enable reuse, it would be useful to have a way to modularise them.

One of the requirements of modularisation for reuse in any notation is to have a method of specifying the contractual interface, such that it is possible for the producers of the modules to change their internal structure without breaking any existing usage of the module.

This paper describes a proposal is for an ixml preprocessor that permits an ixml grammar to invoke other modules of ixml grammars, specifying their linkage. This involves renaming rules with name clashes in the modules, using ixml renaming, resulting in a single ixml grammar with no rule-name clashes, and so that the resultant XML serialisations remain the same. The invoking grammar remains unchanged.

There is no change to the syntax or semantics of ixml proper.

In the autumn of 2024, I attended the XML Summer School and persuaded (it wasn’t difficult) Stephen Pemberton to tack a session on iXML onto the end of his course on XForms. On the bus home, I made a start on my first iXML grammar. Within a week I had encountered a character encoding mystery and whitespace challenges, lost a day naming things and was working on repurposing XSpec for testing iXML grammars.

This paper: outlines my learning journey, as a case study; highlights existing methods for tesing iXML; and summarises how I adapted XSpec for testing iXML.

The need for more XForms controls and functionalities has grown as web applications demand richer user experiences and greater interactivity, while by contrast, the XForms standard didn’t seem to be as fast-evolving as the web. And while there are plenty of great and advanced solutions to address these needs, none of them can be a perfect replacement for XForms.

We are presenting a solution designed for XSLTForms (for now) to extend the capabilities of XForms applications, using XSL stylesheets, JavaScript code, and CSS styles.

Using it, developers can create sophisticated and highly interactive XForms applications featuring controls and functionalities that surpass the limitations of the current XForms standard, making XForms applications more dynamic, interactive, and user-friendly.

It introduces both enhanced functionalities and looks to XForms, allowing developers to build, with XForms, complex applications more efficiently and with better customization.

XSLT 3.0 included support for parsing, navigating, and generating JSON, and this has proved successful and useful. But what hasn't worked so well (see Transforming JSON using XSLT 3.0, XML Prague 2016) is using the traditional XSLT rule-based processing model to transform JSON. There is a project under way to define XSLT 4.0, and one of the aims is to address this deficiency. Some of the ideas for language improvements were floated in (XSLT Extensions for JSON Processing, Balisage 2022) and (Navigating and Updating Trees of Maps and Arrays, XML Prague 2024). But while all these ideas are relevant, I'm not sure they really crack the essence of the problem: to mirror the way template rules work with XML, we need to define what the "nodes" are when we process JSON, what patterns we will use to match them, and what the default built-in template rules should do.

I decided that the only way to get the design right was to do a case study: define a problem that would benefit from recursive-descent rule-based transformation of JSON, and then explore what language features would make the resulting code simple, clean, and efficient.

The case study I chose is the Java-to-C# transpiler used to port the Saxon software from Java platforms to .NET. The transpiler was described in (transpile from="Java" to="C#" via="XML" with="XSLT", Markup UK, 2021). This is a real XSLT application in daily use. It invokes the (open source) JavaParser to emit an XML representation of Java source code, it performs various transformations of that XML, and then finally spits out equivalent C# source code. My basic question is: suppose the JavaParser had chosen to emit JSON instead of XML (as it might perfectly reasonably have chosen to do). Would we be able to write the transpiler in XSLT 4.0 to work entirely within the JSON space, avoiding all use of XML?

I chose this case study for several reasons:

* It's entirely plausible that the input might have been JSON rather than XML

* The application relies very heavily (and successfully) on rule-based processing: if we didn't have template rules, then it would be dominated by large xsl:choose statements with hundreds of branches.

* At around 5000 lines of XSLT, it's large enough to be non-trivial, yet small enough to be tractable as a case study.

It's not the aim of the case study to produce a working transpiler that replaces the code in production use; rather the aim is to explore the feasibility of doing so.

The paper will focus on the reasons that this was not easy to achieve with XSLT 3.0, and the new proposed features for XSLT 4.0 that make the job easier.

At Bloomsbury Publishing, we rigorously validate our specialised DocBook XML and TEI XML against multiple schemas to uphold high publishing standards. While our existing test suite has successfully validated our extensive and continuously growing Schematron schemas, we identified the need for a dedicated validation suite for our Relax NG and XML schemas. The suite is designed to identify pre-existing issues and ensure that any future schema updates or modifications are thoroughly tested. The goal is to maintain a high standard of data validation, by ensuring accuracy and reliability of our content throughout our workflow.

To address this gap, we built an XQuery-based test suite that leverages BaseX (versions 9.5.2 and above) and uses XSLT 2.0 for its results output. Adopting a unit-testing methodology, each schema element is treated as an individual, testable unit. This fine-grained approach ensures that every part of the schema is validated independently, ensuring both accuracy and reliability. The test cases are structured in a pass/fail format, making it easy to identify whether a specific schema element is valid. They can be extended as content diversifies, ensuring the test suite remains adaptable and efficient with changing content requirements.

Once execution completes, the test suite presents an overview of the results within the BaseX GUI, for quick interpretation and diagnosis. Additionally, a comprehensive output of results is generated in both XML and HTML formats, catering to varying user requirements.

The XQuery-based test suite strengthens validation processes and has proven particularly effective at uncovering legacy issues contained within our schemas. It offers a high level of flexibility, efficiency and accuracy, all of which safeguard our high-quality publishing standards.

David and Andrew will use this shared session to foreground some important Schematron updates not all attendees will have had chance to hear about during the Users Meetup, including progress on the latest edition of the international standard and the speakers' own implementations.

People working with large collections of XML documents often need to know specific characteristics of the documents in the collection in aggregate. For example, an attribute value that only occurs once in a million documents might warrant investigation; an element that was expected but that does not occur anywhere might similarly suggest a problem. People designing transformations or style sheets might find it useful to handle the most commonly occurring elements first.

FreqX is an XSLT-based tool that summarizes the various elements, attributes, attribute values, and other details in a collection of XML documents. It can produce several different report formats, including an HTML Web page, a CSV file for a spreadsheet, and of course XML data. It has been run on collections containing tens of thousands of documents, running into tens of gigabytes of XML.

Unfortunately, early versions of the tool used large amounts of memory—several times more memory than the actual scanned documents occupied. This made the tool unsuitable for one of its design goals.

This paper describes some of the design decisions that were made both in the creation of FreqX and in the subsequent revision, and also the process of making the tool support large amounts of data.

Insurance contracts, often referred to as ‘policy wordings’, lie at the heart of insurance – a global industry with total premiums exceeding $7 trillion. Typically, these policy wordings are tens of pages in length, often exceeding over one hundred pages, and are currently managed as monolithic, quasi-static pdf documents.

For commercial insurance contracts, however, there is often a need to customise these wordings to satisfy the needs of individual customers, a process which is currently achieved through the application of ‘endorsements’ (or customer-specific modifications), which are detailed in a separate document known as the ‘schedule’. Therefore, the only way to fully interpret the policy wording is to consult the schedule and engage in a process of information reconciliation.

Using structured authoring approaches with semantic enrichment, the policy wordings could be transformed into dynamic, customisable objects with greater levels of ‘computability’, thereby paving the way towards a more robust, digital future for the insurance industry with greater levels of structured data. This paper concerns the context and initial development of InsurML, an XML markup language to be designed specifically for the creating computable contracts for commercial insurance und helping to unleash a truly digital future for the industry.

The authors will cover recent progress in BSI IST/41 and ISO mirror committee SC 34.

XProc 3.1 comes with many great features for surfing the web. The p:document instruction will load XML, HTML, or JSON documents. The p:http-request step allows a pipeline author to interact with web services. It supports many HTTP methods, query parameters, content negotiation, and single and multipart request and response bodies.

But what about web applications? Web pages that rely on client-side processing, with XSLT using SaxonJS, for example, or just plain old Javascript, present a special challenge. What can we do about that?

Elemental is a NoSQL Database designed for working with documents.

Working with documents is natural for humans, and so Elemental allows you to store, search, transform, and publish your content.

In the previous edition of Markup UK, I examined various methodologies for converting XML to TeX in the context of automated typesetting. Among the approaches discussed was our xml2tex conversion library, which can be configured to accommodate virtually any XML input and TeX output. Alongside the TeX framework CocoTeX, xml2tex constitutes one of the two core components of our xerif typesetting system.

While xerif continues to rely on XML as its input format, all formatting must be specified in TeX. However, TeX’s complexity poses a significant challenge for many users attempting to create layouts themselves. This difficulty is further compounded by the fact that xerif includes its own TeX framework, CocoTeX, which extends LaTeX with numerous custom macros, a custom metadata and table model, accessibility support, and more. This makes layout creation a resource-intensive and time-consuming process, posing a significant challenge for external beginners trying to use xerif with ease.

In contrast to TeX, PrintCSS is considered easy to learn and user-friendly thanks to its familiar CSS syntax. In the field of automated publishing, PrintCSS has gained widespread popularity. PrintCSS encompasses a set of CSS specifications designed to facilitate page layout, content fragmentation (pages, columns, or regions), and content generation (such as running headers, page numbers, and listings). With PrintCSS, HTML or XML can be formatted for paged media output in much the same way CSS is used for styling conventional web pages. However, it does come with notable limitations: The existing specifications lack certain features and, in some areas, remain underspecified.

We believe that generating TeX from PrintCSS is both a promising and intriguing approach. Many formatting capabilities available in PrintCSS can be effectively rendered using TeX. However, the fundamental differences between these two technologies necessitate workarounds and, in some cases, complex programming solutions. Our goal is to showcase the potential of this approach while also addressing the challenges posed by the differences between these paradigms.

The Journal Article Tag Suite (JATS) 1.4 has been approved (as JATS version 1.4 ANSI/NISO Z39.96-2024 on October 31, 2024). The most exciting new capability added in JATS 1.4 is the ability to handle multi-language journal articles, that is, articles where substantial portions, if not all, of the content is provided in more than one language. JATS has always been able to encode articles in any language and to identify portions of an article that are in a different language from the containing article. However, JATS has not, until version 1.4, been able to gracefully encode articles that are in whole or large-part multi-lingual.

As an American Agile Coach and Project Manager who works with teams anywhere in the world, this abstract is a storytelling case study "The Ws of War"—a critical reflection on a failed tech project led by a project manager (PM) whose authority and warnings were repeatedly ignored on Conversion SGML to XML in TC project. It explores themes like poor leadership, ignored risks, emotional dysfunction in teams, and the consequences of sidelining a capable PM and how that snowballs a project. Ultimately, it highlights the importance of letting PMs lead with clarity, strategy, and authority to avoid chaos, cost overruns, and project failure.