At Markup UK we are likely to hear presentations about creation, maintenance, and use of specific tag sets. We are likely to hear more presentations that focus on some aspect of creation, interchange, manipulation, use, or archiving of document content encoded in one or another shared tag sets. In both cases, we will focus on the tag set or the documents, but not on the social forces that shape the tag set and that are shaped by the tag set.

The public tag sets: TEI, DITA, UBL, JATS, HL7, BITS, STS, DocBook, HTML and hundreds (perhaps thousands) of others were created by groups of people to meet specific needs. The needs of those groups, and the changing needs of the various members who have joined or left these activities, have shaped the tag sets. Things the membership, or the sponsors, or the most vocal/powerful members, think are important are enabled and/or emphasized. We are seeing more and more tag sets providing the ability to enhance documents with accessability information as access becomes more important in the world in general.

Conversely, shared tag sets, and the assumptions that underlie them, shape the world view of their users. Before HTML it was common to build tagging structures that allowed paragraphs to contain lists; these days that is considered surprising. Before SGML and XML it was not unusual to discuss how to capture the overlapping structures in texts; now it may be considered a “corner case”, and to many it is simply unthinkable. The communities around various tag sets may pressure users to encode information they do not need in documents because the community expects it: TEI users may feel pressure to provide metadata, JATS users to provide richly encoded citations, HTML users to use more generic tags in place of visually descriptive tags.

Shared tag sets are much more than lists of codes, they are powerful and dynamic social constructs that influence and are influenced by the world.

S1000D is a specification for tech pubs which has been broadly adopted in the aerospace industry. It provides XML schemas for common doc types and defines how these documents should be structured in a common source database. S1000D is replacing the ATA SGML format as the primary spec for OEM aircraft manuals and is used for new aircraft such as the Boeing 787 and Airbus A350. At the same time, mobile devices are playing an increasing role in aircraft maintenance, allowing engineers to access technical information at the point of need.

Airlines are pressured to keep fares low but still maintain the highest safety standards. A single source for engineering content is one way to reduce overheads. It follows that other documents for engineers should also be S1000D to allow common tools for managing and rendering content.

This paper discusses implementing S1000D for a major UK airline’s engineering procedures. While OEM manuals cover much information needed by engineers, airlines still need their own procedures for topics like health and safety, planning and quality control. In fact, to cover all aspects of keeping aircraft functioning safely and comfortably for passengers.

S1000D can be daunting for the inexperienced though. The version 4.1 spec is over 3500 pages long and not an easy read. There is a shortage of S1000D information in the public domain, perhaps because it is still quite new, the majority of aircraft manuals are still in SGML and the industry is understandably cautious about change.

Of course, you could skip the spec and just start creating some S1000D schema compliant XML, only referring to it when you hit a snag. This is a very bad idea. By this time, you will likely have created a number of problems for yourself which will be hard to unwind. This paper will explain some of the design decisions you need to make before going anywhere near a keyboard and hopefully save you from some of the pain that you will inevitably experience.

This paper describes two models for semantic markup of bibliographic references, their advantages and disadvantages, and the challenges of automating a conversion from one format to the other.

In one format a reference is captured as plain text. The semantic markup (author name, title, publication date, etc) is captured in attributes on the element containing the reference text.

The other format is BITS, where each component of a reference is captured in its own element. The BITS model comes in two flavours, <element-citation> and <mixed-citation>, hence the extra half a model in the title.

The conversion to BITS needs to support OpenURL linking and the Initiative for Open Citations (I4OC).

In a quick crossword, the relationship between clue and answer is usually simply definitional: the clue offers a definition or description of, or a synonym for, the answer. In a cryptic crossword, the relationship between clue and answer is significantly more complex, and may be one of many types. Anagrams, puns, hidden words, deletions, reversals, and other techniques are used, often in combination. Every word in a clue does one of three jobs: a) defining the answer (a synonym or definition of the answer word(s)); b) producing part or all of the answer word; or c) indicating how the words in b) are to be manipulated. It follows that each part of an answer will relate back to one or more words in the clue from category b), while the whole answer will relate to the word(s) in category a).

This paper will describe the early work of creating a markup scheme which relates each part of a cryptic crossword clue to the relevant part of its answer, as well as giving full linguistic detail for each word. The aim of this project is to create a corpus of cryptic clues and answers which can be explored to answer linguistic questions. Examples of questions that might be asked of the data include:

Do crosswords in different newspapers use the same or different category c) words to indicate letter reversals?

Do anagrams tend to require the use of less-common vocabulary than other clue types?

Are category c) words always verbs? If not, do different techniques have different ratios of parts-of-speech from each other?

The paper will consist of four parts:

1) A brief introduction to cryptic crossword clues;

2) The project aims;

3) Description of problems encountered in the early stages of the project and the steps taken to solve them;

4) Examples of progress so far, and description of next steps.

This paper proposes a system to aid in the drafting of amendment documents. The system provides a mechanism to help validate the correctness of amendments. Furthermore the system is able to semi-automatically sort the amendments in voting order and simulate the effects of amendments on the law. The proposed implementation is based on XML technology, an XML editor and machine learning.

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 tutorial takes an eat-your-own-dog-food approach to showing how to use CSS for paged media. Starting with the HTML text of a comprehensive, new 140-page (when formatted) 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.

The project "Emblematica Online - Linked Open Emblem Data" set out to publish the Wolfenbüttel collection of emblem books as a resource for digital emblem studies. At the end we managed to publish information about approximately 12300 emblems and 220 emblem books.

After a short introduction into the field of digital emblem studies at the Herzog August Bibliothek Wolfenbüttel the article presents the challenges we faced when working with XML encoded information that dates back to the beginnings of web and the infancy of today's Digital Humanities, the solutions we employed to tackle these problems and how we ended up implementing a publication pipeline implemented in XProc.

Some of the topics I like to discuss are missing documentation and schema validation, legacy technology (i.e. DTD), the creative use of XML specifications, and an unexpected kind of vendor lock-in, i.e. being dependent the parsing quirks of the open source XML processing environment PHP + libxml, and the benefits of XProc as a declarative language for XML processing pipelines that allowed us to quickly iterate possible solutions.

Which character in Unicode are you willing to accept? If you receive UTF-8 text from somebody, it might contain any of the 136,690 code points of Unicode 10.

Accepting any Unicode character may lead to problems in the future. First, nobody can read all characters. Second, few fonts cover all characters. Third, some software such as document editors support only a subset of Unicode.

Historically, legacy encodings have protected users from the proliferation of characters. For example, as long as you use Shift-JIS, you only have to worry about 7,000 characters. But UTF-8 now exposes almost 88,000 CJK ideographic characters.

In the Unicode era, we need a language for describing which character is to be allowed and then examining text aganist descriptions in this language. ISO/IEC 19757-7 Character REPertoire Description Language (CREPDL) is an attempt of ISO/IEC JTC1/SC34 for such a language. CREPDL can also be used for desribing the character repertoire of a font.

A code generator for document to document transformation is introduced. It reduces the development effort to editing a set of metadata items attached to a tree model of the target documents. Metadata values are XQuery expressions which are typically so simple that they do not require genuine programming skills. Nevertheless, expressions are more difficult to provide than static values, and therefore possibilities of further simplifying the development task are explored, striving to enable subject matter experts to define the transformation without writing XQuery expressions. This can be achieved by generating the expressions from assertions about alignments between source and target nodes, although specific requirements will often necessitate additional information. As alignments can be represented graphically by connecting lines, the approach amounts to a solid conceptual foundation for graphical mapping tools. Finally, the underlying model of code generation driven by target document structure is generalized into a conceptual framework which is not restricted to XML data sources. Its usefulness is demonstrated by a simple code generator for transforming RDF data into XML documents.

XProc 1.0 is clearly an XML-centric language to design workflows, actually it is mostly an XML-only workflow language. This is fine for a lot of tasks, but it turns out, that even workflows dealing mostly with XML documents have also the need to deal with non-XML data. Just think of an ePUB mostly containing XHTML documents, but also having some JPEGs with illustrations, a manifest file which is pure text and finally been essentially a special kind of ZIP-document.

As such workflows shows up quite often in real day life, the ability to deal with non-XML documents was a high priority requirement when developing the next version of XProc, which is called XProc 3.0.

In this talk I would like to give an introduction to workflows for non-XML documents in XProc 3.0. To do this as practical as possible I decided to layout a typical workflow involving the necessity to deal with non-XML documents and to show you, how this could be done in XProc 3.0. Of course the workflow is a little bit of a made-up story, because it was chosen for the purpose of demonstration. But I think you will get an idea of what you can do with XProc 3.0 and will be able to apply it to your real-life use cases.

So the workflow is this: We have a bunch of ePUBs in a folder somewhere and we have been asked to design a workflow which analyses the content of the ePUB and creates an RDF metadata description and an inventory which has to be send to one of our inventory-servers which --for what reason ever-- happens to understand only JSON. I will explain the details of this workflow later, but please keep in mind that it involves dealing with a lot of non-XML documents such as ZIP (the ePUB itself), plain text, graphics in JPEG, RDF and last but not least JSON.

The talk is divided in four parts, where the third part is the central one:

- Reminder: Non-XML documents in XProc 1.0

- The new document model in XProc 3.0

- Applying the model to design non-XML workflows

- Conclusion

Many teams struggle with defining, documenting and following proper processes. A case study is described where a content delivery team of a major digital publisher was experiencing these problems when running transformation pipelines using XSLT and Schematron, as well as numerous other XML related tasks. The use of the Apache Ant build tool has allowed them to create a set of tools that to enforce an agreed development policy using a set of reusable macros. These macros have allowed the team to dramatically increase the build quality of deployed code, as well as to getting new team members productive more quickly. This experience has spurred the development of an open source equivalent of this macro library (whimsically entitled "XPantS") which is also described.

This paper will present a successfully completed project to write an XSD 1.1 validator using XSLT 3.0.

There are several motivations for attempting this; the most immediate was the need for a schema validator to run in the browser, and given the existence of XSLT 3.0 in the browser (in the form of Saxon-JS) writing the validator in XSLT 3.0 seems a more attractive choice than the alternative, of writing it in Javascript. The portability benefits of being able to do schema validation anywhere you can run XSLT 3.0 are an additional factor.

Possibly too, wider availability of XSD 1.1 validators will encourage those who publish XML Schemas for common standard vocabularies to take advantage of the powerful features introduced in version 1.1 of the XSD standard.

The second motivation was simply as a usability test of XSLT 3.0: this is a complex application, and it is useful to see whether XSLT 3.0 is up to the job.

The validator takes as input (a) the XML representation of the schema produced by compiling the XSD source under Saxon-EE (this is known as an SCM file, for schema component model), and (b) the instance document to be validated. As output it produces an XML report detailing the validation errors found (which can then be rendered in HTML using a further transformation, if required).

The overall conclusion is that it has been possible to write an XSD 1.1 processor with a very high level of W3C conformance using pure XSLT 3.0 code: the tools proved up to the task.

The issue of how best to represent overlapping hierarchy in XML has been the topic of a number of papers over the years. This paper is a further contribution to this important issue, but approaching the problem from a different direction. Our goal is to represent changes to documents, and one type of change is change to the markup hierarchy. Therefore our ultimate goal is to be able to represent not only changes to the hierarchy, typically resulting in overlapping hierarchy, but also changes to attributes and text. This is a more ambitious goal than simply representing overlapping hierarchy, and one aspect of this is to make a clear distinction between the different hierarchical structures and the text that corresponds with each one.

XForms 1.0 and 1.1 both had test suites that consisted largely of static XForms documents. To run the tests you had to manually activate them one by one, and then visually confirm that the test had passed. If you wanted to add more cases to a test, it involved adding to the set of documents, or editing the individual documents.

The test suite for XForms 2.0 now being constructed takes a different approach, the idea being that the tests should check themselves that they have passed, and most tests have a similar structure so that only data used needs to be altered to check new cases.

Of course, for a language designed for user-interaction, some tests have to be based on physical interaction. But once you have confirmed that clicking on a button does indeed generate the activation event, all subsequent tests can generate the activation event without user intervention.

The introspection needed for tests to check the workings of the processor doing the testing can raise some challenging problems, such as how to test that the initial start-up event has been sent when the facilities for recording that fact have not yet been initialised.

This paper will consider the techniques used to create a self-testing XForms test suite, the problems encountered, and how they were solved.