Proposed: “The Non-Oxford/Non-Webster Dictionary, Patrick Durusau, Editor, shall invent new means of identifying the meaning of previous words and a means for processing them.” Despite computer science precedence this approach, no known dictionary has ever used it. Much like the “Attention is all you Need” linguists, dictionaries rely on existing data as a starting point. As a practical matter, as well as human nature, users prefer names they already know for subjects; witness the persistence non-standard names or terminology, long after new lists have been invented. Character sets and Unicode points are one example. The Semantic Web took that a step further and invited users to create, at their own expense, identifiers for subjects they knew by other identifiers. An origin paper sums up the problem we face with identifiers this way: It turns out that given any term, there are many possible subjects that it could denote (to a greater or lesser extent) and conversely, any particular subject of knowledge (whether broad or narrow) usually can be denoted by different terms. What if instead of adding to the sea of identifiers for subjects, we take inspiration from probabilistic database and large language models to develop a data-driven approach for subject identity? Instead of a universal exactness of subject identity, the degree of certainty or rather uncertainty, is acknowledged as a matter of design.
Is invisible XML ready for teaching university undergraduates? Is it a good idea to try this? This paper will attempt to address these questions. University students in the Digital Media, Arts, and Technology program at Penn State Behrend are offered a course in “Large-Scale Text Analysis”. Going into this course, students have experience in encoding text with XML, transforming XML with XSLT, and web development with HTML and CSS. In the past, the Text Analysis course has been a procedural “Regex-and-Python course”: preparing text corpora by generating simple XML from regularly-patterned files using regular expression search-and-replace operations, using XQuery to extract the portions of the texts to analyze, and producing plain-text inputs to provide to Python. Python has dominated the experience of the pipeline. This year’s course tried a different approach. Students were taught iXML grammars as a way to prepare XML for analysis and XProc for pipelining. Regular expression matching involved working with XSLT, and the entire XML stack was used before approaching Python. Students learned how to install software in alpha stages, and they tested how well it works across platforms. From this exploratory start, one student project team found a very practical use-case for applying invisible XML in a project pipeline for analyzing chord chart musical notation. In this paper, we discuss the potential we discovered for invisible XML in music analysis. We also share our recommendations for guiding people to prepare processing pipelines that incorporate invisible XML, and we reflect on what aspects of this risky teaching experiment were most worthwhile.
Many of the new SaxonJS 3 features have been developed in response to issues that were originally raised by SaxonJS users. "Here's a problem I'm trying to solve. This is what I can do. But what about X? How can I do it with SaxonJS?" Sometimes the SaxonJS 2 solutions may be somewhat unsatisfactory - yes we can code that; but the code isn't especially "pretty", or intuitive, or easy to write... or perhaps there remain limitations... In some cases, there was actually a limitation with the SaxonJS 2 processor - for instance perhaps it is not possible to do what the user wants only with XSLT and IXSL, but instead integrating a JavaScript solution is required. In other cases, the SaxonJS 2 solution is perhaps just rather complicated, and requires putting features together in an unfamiliar way. In this paper we will look at how new SaxonJS 3 IXSL features can be used to write much cleaner solutions for some problems which were tricky with SaxonJS 2.
This paper explores using module URI resolvers to modify the source module at resolution time. The motivating use case is to provide type-based templates for function libraries. Other examples are given, followed by an examination of the advantages and pitfalls of this approach.
The paper compares several ways to structure a transformation consisting of a sequence of steps, each building on earlier steps. Most of the steps are written in XSLT. The steps are connected in various ways, including with XSLT modes and variables, with the XPath 3 fn:transform() function, with XProc steps, with the Unix command-line make program, and with a batch shell script. The methods are compared in terms of maintainability: skills and knowledge needed; managing interdependencies; difficulty of revision; ease of reuse. Recommendations for structuring multi-step XSLT transformations are made that depend on context, on people, on data, with guidelines included to help project designers make the choice.
Taylor & Francis is working to develop a transformation process to convert a large archive of journal article files from an obsolete XML DTD to the current version of JATS. Two essential design principles guide the project: fidelity and usability. Fidelity guarantees preservation of all content from the original files, ensuring nothing is unknowingly lost. Usability ensures the transformation is easy to use in a variety of scenarios—from staff processing individual files to automated batch transformations of numerous files. Implementation required resolving multiple technical challenges inherent in the obsolete format while addressing complexities arising from strict design principles. To validate accuracy of the transformation, a specialized comparison tool was created that identifies content missing in the output XML compared to the input XML. The approach is analysis-driven, involving comparison of the two DTDs, and utilizing standard technologies including XQuery 3.1, XSLT 3.0, BaseX, Saxon, XSpec, and DTDAnalyzer.
Finnegans Wake by James Joyce is probably the hardest book to read in the English language. A principle hurdle is the length and convolutedness of the sentences. This paper reports work-in-progress of an attempt to handle the complexity of Finnegans Wake by parsing the sentences (at a structural, not a semantic level), to reveal their top-level structure. It takes the reader step-by-step through the construction of an ixml grammar for dealing with one chapter of the book.
Schematron (ISO/IEC 19757-3:2008, 2016, 2020) is widely enjoyed as perhaps the most expressive and powerful of all XML schema languages. In this article, I argue that Schematron is profitably seen as a kind of API (application programming interface) for a constrained flavor of XSLT. This outlook has immense benefits, because when we act on that insight, Schematron’s horizons expand to those of XSLT. Anything an XSLT can create can be reported in Schematron, and together they can conquer the world. I present four models of validation that closely partner XSLT and Schematron, and offer suggestions on how that partnership can be strengthened in the future.
This paper proposes a simple approach to labelling the language of programming code embedded in structured documents, using standard language attributes (such as xml:lang and HTML lang ) with a single reserved language code qpr , and specific programming languages and/or data formats distinguished via the following portion. This approach facilitates language-specific processing including syntax highlighting, spell checking, and validation while maintaining backward compatibility with existing document processing systems.
Conferences are events at which people converse. That is, people talk with each other, learn from each other, enjoy interacting with each other. Performances are events at which the audience watches the performers. Balisage is a conference, not a series of performances. At Balisage , like at most conferences, speakers give presentations. Those presentations are interesting and valuable in and of themselves. But the active discussion after the presentations is the real point. That discussion, based on the content of the presentation, is fueled and shaped by questions and comments. This is why it is important that at Balisage we think carefully about the questions we ask. Good questions prompt the speaker(s) to expand on interesting points, allow the speaker to clarify, to extend, and to explain. Good comments support the speaker. It is important that we refrain from asking questions that demean the speaker, minimize the content of the presentation, or that are designed to show off the questioner’s knowledge at the expense of the speaker. At Balisage we allow substantial time for questions and discussion after each talk and at the beginning and end of each day. Please help us make Balisage lively, interesting, and interactive by crafting questions that lead to lively and interesting interactions.
Foxpath, short for folder XPath, is an expression language that enables XPath-like addressing of the files and folders in a file system. Both file systems and REST resources addressable through URIs can be thought of as a tree of folders, and thus navigated by path expressions in Foxpath. Foxpath is a superset of XPath 3.0 with node tree navigation retained but file system navigation added and a free combination of both functionalities allowed within a single path expression. Foxpath is a language with a strong focus on interactive use and the power of succinct expressions. Invisible XML allows us to extend Foxpath navigation to more resources. A new configuration mechanism associates grammars with file name patterns, enhancing the experience of a pervasive tree structure which we call an infospace.
Tired of hallucinations from large language models? A solution may be to give them not just better data or more data, but prompts with better structured data. Reducing hallucination has heretofore been approached by supplying better contextual narratives in prompts. However, recognizing that knowledge is best represented by graphs leads to the suggestion that XML may be a better fit for input to LLMS than either RDF or JSON.
A W3C Community Group has been formed to develop proposed specifications for 4.0 versions of XSLT, XPath, and XQuery. One of the aims is to provide improved capabilities for processing of JSON, and the associated constructs in the data model such as maps and arrays. This paper describes a new capability that has just been added to the draft specification, allowing navigation of trees of maps and arrays using the familiar path expressions of XPath 1.0, largely unchanged in syntax.
The Text Encoding Initiative has had a web presence for almost thirty years. It's instructive to consider how a large, robust, and widely-used XML vocabulary defines its presence on the web. How it has weathered the storms of change (management, institutional, technological) to be where it is today. And how it imagines its future.
XML has a highly reliable, consistent, widely-supported ecosystem. Python is enormously popular, yet (perhaps surprisingly) its support for XML has weaknesses. Several parsers are available but most (including the “official” xml.parsers.expat) are not native Python, leading to issues with Python development tools. The Python DOM library (xml.dom.minidom) is native, but is barely DOM 2.0, slow, and lacks conveniences well-established elsewhere. It is also not “Pythonic,” using few modern Python features and idioms. lxml is admirably Pythonic for Elements, but text poses problems. Ragnarok is a new, pure Python XML tool suite that addresss these issues. It provides plug-compatible replacements for Python XML libraries, and is equipped with many Pythonic conveniences (the “batteries included” philosophy of Python). The parser ( Thor ), uses recursive decent: methods map directly to the XML grammar, easing debugging and extension. A validator ( Heimdall ) is in progress. Schemera handles DTDs, but its architecture is more like XML Schema. The DOM library ( Dominµs , aka Yggdrasil ) is much faster than minidom, with almost all of DOM 3 Core and many features drawn from other XML and HTML tools and from Python practice. Flexible output serializing comes via components called Gleipnir and Bifrost . Non-hierarchical structures have long been of interest to this community, but face a dilemma because XML doesn’t really support them: one can coerce to XML syntax via milestones or standoff markup; or create entirely new syntax. In either case XML tools give little help. Beside Thor, Ragnarok also includes a second parser, called Loki , which explores a middle way. Loki accepts non-hierarchical structures via syntax that includes non-XML extensions, but remains so similar that (a) no prior WF XML changes meaning, and (b) the implementation is easily constructed on top of a regular parser. This may enhance data and code re-use. Loki is a subclass (rather than brother) of Thor, and like its namesake can change its shape. Loki can be configured with many XML-adjacent options ranging from case-folding names or enabling named character entities (both difficult with many other tools), on up to extensions for olists, suspend/resume, and milestone-encoded structures. Ragnarok overall can help with everyday XML tasks in Python by being faster, more up-to-date, more Pythonic, and more fully functional. On the other hand, Loki can help with overlap and a variety of other tasks at the edge.
This report explores strategies for grammar-based parsing and processing of next-generation markup languages , a term we use to describe markup languages that are designed to be able to represent structural Overlap , Discontinuity , and other features that are not easily managed in XML. Because next-generation markup languages cannot be modeled fully as context-free grammars (CFG), we employ a mildly context-sensitive grammar (MCSG) to validate documents with next-generation markup against user schemas expressed through an extension of Relax NG compact syntax (based on Creole).
Just Another CMS , JACMS for short, is the evolution and current iteration of the author’s long-standing dream to create a content management system using XML technologies and tools. JACMS, a content management application built on top of eXist-db, is very much a work in progress, and whilst this paper started as a tale of the entire system, from authoring to publishing and everything between, that approach turned out to be prohibitive. As a sanity-saving measure, the author eventually decided to focus on JACMS’s version management, itself based on XML. JACMS’s version handling is based on Version Markup Language (VML), a versioning abstraction designed to identify “meaningful” versions on an arbitrary number of levels, e.g. 1.2.3.4.5, etc. The implementation, on-going at the time of this writing, is written in XQuery and XSLT, with the UIs produced by XForms, and includes not only VML instances and code to describing and managing version histories but also an extended XLink linkbase.
As users begin to explore using XProc 3.x pipelines, and migrate existing 1.0 pipelines to 3.x, they naturally have questions about how to tell if a pipeline will work and will produce the correct result. This breaks down, broadly, into four categories: is the pipeline written correctly: is it syntactically valid; is the pipeline written correctly: is logically valid; does it do what the author intended: does it produce the correct results; and if it doesn’t, how can the author figure out why?
Balisage 2024 included a short-subject “Open Microphone” session, during which conference attendees were invited give 2-10 minute presentations on any topic relevant to the conference, including specification updates, new tool announcements, and demonstrations. This short presentation discussed proposed updates for ISO Schematron’s 4th edition, including a number of new elements and attributes. At the time of the presentation, work was at the Committee Draft stage, with publication of the standard anticipated in September 2025.
