Conference Programme

CSS can be used for making pages as well as for styling websites. Many people are familiar with CSS in the browser: some are very familiar, but others, not so much. Fewer people, however, are as familiar with using CSS for paged media.

This session takes an eat-your-own-dog-food approach to showing how to use CSS for paged media. Starting with the HTML text of a tutorial on using CSS with paged media, the session will progressively add and explain the CSS styles that are used to format the finished text. By the end of the session, the fairly undifferentiated mass of text will be formatted with running headers and footers, page numbers and page number cross-references, bleeds, CMYK colours, footnotes, top- and bottom-floats, and other features that appear in paged media but not in a browser. The session will also describe accessibility features of PDF.

Because of the comparatively short duration of the session, there is only time to cover the CSS features specific to paged media. There will also not be time for everyone to install AH Formatter at the start of the session. If you want to perform the steps using your own laptop, it is necessary to have AH Formatter installed before you come. Evaluation versions of AH Formatter for Windows (and Windows GUI), MacOS, and Linux are available from https://www.antennahouse.com/formatter/.

We are overwhelmed by competing standards, technologies, and approaches to solving problems we may or may not understand and may or may not have anticipated. Each of us individually, and we as a community, have limited resources and want to concentrate our energies where they are most likely to be successful. Selection from among the cornucopia of options is often made more difficult by our preconceived notions of the shape, source, and promulgator of appropriate technologies. In many cases we seek, and occasionally we find, a powerful tool that seems to address all of our problems. The quest for such tools has led many of us to become standards junkies or technology evangelists. The belief that we have created or identified such a tool leads some of us to become missionaries promoting the use of a standard, a paradigm, or even a tool. In the children's book "Everyone Knows what a Dragon Looks Like", illustrated by Mercer Mayer, Jay Williams raises questions about the recognition and appropriate use of powerful tools. From it, we can learn to be little more skeptical of our ability to know the tools we need when we see them.

The statement that XML is dead is as wrong as celebrating Christmas on midsummer night’s eve! Imagine making an archival soup based on international standards using XML, with one municipal archive, two regional archives, five national archives and the European Commission’s eArchiving Building block thrown into the mix. This is what we are going to attempt.

Since the first days of SGML, there has been a variety of software to parse, validate, analyse, format, store, search, and extract the information. Some of this was what we now call Open Source, particularly the utilities, but the majority of applications were normal commercial offerings.

In the course of time, many of these have become unavailable, for assorted reasons, with the result is that some very useful systems have been lost, and replacements are not as effective.

This research attempts to catalogue and analyse a collection of XML and SGML software that is either off the market, or only available within a different product, and thus not accessible to users. The objective is to see if there are still ways to “shorten the distance between the bricks” that are not otherwise provided for.

A visual XProc editor can serve at least two purposes: Communicating the process flow to non-programmers and easing the notoriously steep learning curve for programmers.

An implementation using the Javascript framework joint.js and the in-browser XSLT 3 processor Saxon-JS is demonstrated, along with the challenges of supporting XProc’s peculiarities in a generic graph editing framework.

The paper describes an implementation of an xqDoc.org documentation generator. A focus of this implementation is XQuery annotation support. In 2014 the xqDoc schema was updated to include markup to capture XQuery annotations, however existing renderers have often not been updated to make use of this.

A major driver for annotation support is documenting XQuery web applications built using the RESTXQ standard. RESTXQ defines a standard set of XQuery annotations that can be used to define RESTful Web Services from XQuery. Annotations are also being used to define frameworks for unit testing, user permissioning and web socket interfaces. Annotations are code markup that the runtime environment may choose to use to wire-in additional external functionality to XQuery applications.

The xqdoc implementation is open source. It is largely written in XQuery and runs with recent versions of BaseX. It generates static, stand alone HTML5 and XML output. The included XQuery library modules can also be used to assist in the generation other related documentation artefacts. In the case of RESTXQ these could be the generation of openAPI(swagger) and WADL documents.

A data worker is a running program which manipulates data. It can get data from various sources then transform it and save, or send, the resulting data. A common usage for data workers is interfaces between applications.

XQuery is a data-oriented language which is not bound to databases and which is able to format data conveniently as text or XML. Many implementations have added function libraries to access file system, send HTTP requests, and so on... XQuery is a high-level programming language because repetitive operations such as loading a document from anywhere just requires the minimal information to be provided.

Considered requirements for a new open source XQuery implementation have been no platform limitation, light deployment, extensibility, asynchronous processing, no big pressure on performance: Javascript+NodeJS has been chosen (with possible, but limited, run within browsers).

This implementation is named “Fleur”. It supports XQuery/XQuery Update Facility 3.1 (not full conformance yet) upon its own DOM Level 3 (and browsers DOM). XQuery source is compiled into XQueryX structure which is stored in a Javascript array of arrays.

Fleur can process non-XML documents as XML documents with extensions at DOM level. Internally, Fleur manipulates everything as nodes, computed values been always stored into orphan atomic nodes.

Parsing/serializing non-XML sources is then implemented just at DOM level according to media-type. Experimentally, CSV files and Excel files are directly loaded into 2-dimension sequences.

Fleur CLI includes the possibility of launching an HTTP server. This server executes .xqy pages. XForms, with XSLTForms, can be used to both submit parameters as data to the Worker and render data returned by the Worker.

Fleur has already been used in various situations (XLSForm to XForms, dashboards, OFX conversion). Fleur will be integrated in XSLTForms for XForms 2.0 compliance. XForms actions could then be developed with XQuery Update Facility syntax.

This paper will introduce an operational perspective: how a research question and master thesis ended up in practice and turned into a product. We want to show which requirements led to the solutions, how they were implemented, and which problems still remain to be solved.

One of the main application areas of XML is the exchange of data between business partners. The data is in an agreed structured form that will usually be checked at the receiver’s end. It needs to be “validated” such that syntax and values of the data respects rules made in the agreement. But not only the receiver needs to check the data. To avoid rejection by the receiving business partner, the sender might want to verify that the data does not break any of these rules. Often such document data is made not only for one purpose and receiver, different business partners may have overlapping but slightly different rule sets and use-cases.

This is especially true with publishing-houses or media companies, where players share lot of the same grammar and constraints on data, yet each format has been enriched with some “house- rules” and recommendations that vary slightly. For instance media subtitles encoded in TTML might be perfectly valid according to a given schema, but still in violation of guidelines, business rules and recommendations.

There are some pieces of software, and some formats, that are de-facto standards and have been around for decades. One of these is the diff3 format for representing changes and conflicts in text documents. Diff3 works well for unstructured text documents that are divided into lines. It works surprisingly well for pretty-printed source code and similar documents. But it has frustrating limitations when used for XML or JSON or similar tree-based data formats.

Can we improve on diff3 without making it too complicated? Can the existing representation of changes and conflicts be extended to handle tree-based data? This paper seeks to answer these questions and to describe how further benefits can be enjoyed by using XML or JSON as the basis for showing conflicts and changes.

As a retirement 'hobby', somewhat removed from the computing milieu, the author has started building a model railway in his garden. Surveying the extant tools for designing such layouts and finding them not quite right, he started building a design tool himself, using the familiar technologies of XSLT3 and SVG executing in a browser, employing Saxon-JS as the processing platform. The results of this were demonstrated, with some success, at Markup UK in 2018. This paper describes the design of this tool in some detail, as well as developments since that demonstration.

The Schematron QuickFix (SQF) language can be used to improve efficiency and quality when editing XML documents. You can define actions that will add complex XML structure in your documents, or make modifications in multiple places, or actions that will convert an XML structure into another. These changes are made by keeping the document structure valid and conforming to your project specification, and will help the content writer add content more easily and without making mistakes.

To build complex actions, you can mix Schematron QuickFix language with ISO Schematron, or with different versions of XSLT and XPath, or you can define your own extensions using programming languages such as Java. This means that you can perform modifications in multiple external documents, or display dialog boxes to get input from your users, or use complex algorithms for processing the content of the documents.

The Schematron QuickFix is a modular language. Even though it is simple (it only has four types of operations that can be performed: add, delete, replace, and string replace), new types of operations can be created (such as wrap, unwrap, rename, or join). This can be implemented by using abstract quick fixes and by creating libraries of quick fixes that can be reused for various different XML vocabularies (such as DITA, DocBook. TEI). By using a library of quick fixes, it will help the Schematron QuickFix developers to create the actions more easily and reuse the quick fixes created by others.

This presentation will focus on some interesting use-cases and Schematron QuickFix examples that can be easily adapted to your projects. The examples will include both abstract quick fixes and complex quick fixes that use XSLT and Java.

XML, by itself, does not have any support for accessibility. XML is extremely flexible, but it needs to flex in the right directions if it is going to support the information necessary to make a document accessible. This session is a guided tour of some of the features of the HTML, Web Content Accessibility Guidelines (WCAG), and PDF/UA (Universal Accessibility) standards. It concentrates on file formats rather than User Agent behaviour, since the information needed to make accessible HTML or PDF usually needs to be included in, or able to be inferred from, the source XML.

However, it’s rarely the raw XML that is presented to users. The session will also stray into some aspects of styling the content to make it more accessible.

Whether by reacting swiftly to shifting market conditions and disruptive technologies or by growing through mergers and acquisitions, the ability to adapt is critical to success in the digital age.

As business processes and workflows evolve, new technologies and systems are constantly introduced to support them. Over time, IT estates become fragmented, and the number of legacy systems increases year by year. Valuable data ends up in isolated silos, only accessible via unnecessary applications that are expensive to maintain and license or are approaching the end of life.

This paper suggests a generic approach to transform arbitrary relational data into aggregated, hierarchical form and build a thin application to provide read access to end users.

In my presentation, I would like to point out why the relational model falls short when it comes to data aggregation.

XML can easily model both relational and hierarchical data. It's an excellent choice for data re-modeling and also for building a thin, data access application.

The approach I want to share with the audience is based on experience from multiple projects.

XML "bricks" used in the solution:

• processing pipeline configuration as XML (Apache Ant)
• XSLT
• XQuery
• XML Database

There are lots of XML structures that need some kind of end-user documentation to be able to use them effectively. Its not easy to come up with a format that is both easy to understand and easy to create and maintain. Existing software for this is not always helpful. This talk will explore the this subject and look at from various angles.

Popular conference management systems are monolithic solutions that are used across many fields and by very diverse audiences. As a result, these systems have rigid technology choices for paper format: PDF, TeX or Word which have limitations compared to a structured format such as XML. In addition, they do not cover all the steps in the paper submission lifecycle such as: collaboration between authors.

We propose a new solution for conference paper submission management that tries to improve the user experience in several areas: authors tooling setup, collaboration between authors, multi-step review processes, multi-format proceedings publishing.This paper will present a typical conference paper submission workflow and identify its steps, the stakeholders and the tools and technologies used. We will then present how our solution improves user experience of each of the stakeholders.

In this solution, the documents are authored in the an XML format, that supports publishing both as PDF and web portal. The output format is customizable and clearly communicated to authors so that they can preview how the paper will be published. Authors have a very intuitive user interface to draft the paper and to collaborate in cases where a paper has multiple authors. Reviewers can choose to review either the published PDF or directly on the source. In case of multi-round reviews, they can see the changes made between different revisions, thus being able to focus on the last updates.

From a technical point of view, the solution is composed from off-the-shelf Web services with a thin layer of orchestration. It may to be used together with a regular Conference Management System, replacing parts of its functionality.

To conclude the paper, we analyze how this solution is similar with other workflows related to content creation in a company, such as creating release notes or datasheets for a product.

Misunderstandings about the goals and strengths of different document and data interchange formats can lead to suboptimal decisions. Such misunderstandings appear widespread. The purpose of this paper is to suggest areas in which each format has strengths, and to provide clear explanations that people can use to place XML in the context of other current markup systems.

Misconceptions about XML include statements such as “XML was designed for Web services and therefore unsuitable for documents;” “XML was designed to replace HTML and has failed;” “XML cannot transmit semantics of any kind;” “XML is dead.” In fact, XML is alive and well.

I needed a way to validate that the value of tei:rendition/@selector was a proper CSS3 selector. So I wrote a regular expression to do so. An 18,385 character long regular expression. And it seems to work.

Running XSpec tests in a development team is usually performed via a CI server/service. However, this comes with limitations related to the use of private repositories and to the cost and burden of administering CI servers.

This paper describes an alternative approach for running XSpec tests from private repositories using a serverless architecture built on AWS Lambda. It describes the technical configuration and discusses the benefits, cost optimization, and constraints of a serverless architecture for running XSpec tests.