<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="stratml_AI_Highlight.xsl"?>
<StrategicPlan xmlns="urn:ISO:std:iso:17469:tech:xsd:stratml_core" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <Name>Balisage 2026 Program</Name>
  <Description>Balisage has been an annual conference devoted to descriptive markup, how to use it to best effect, and what it means for technology, access to information, and the preservation of information for the future.</Description>
  <OtherInformation>Submitter&apos;s Note:  This StratML rendition was compiled from the source by Claude.ai and reviewed in the form at https://stratml.us/forms/Claude/Part1.html</OtherInformation>
  <StrategicPlanCore>
    <Organization>
      <Name>Balisage 2026: The Markup Conference</Name>
      <Acronym>BS2026</Acronym>
      <Identifier>_b4c72f11-3a2e-4d89-b7c1-92e50fa8d3c4</Identifier>
      <Description>Balisage is an annual conference devoted to the theory and practice of descriptive markup and related technologies for structuring and managing information. The 2026 conference is the final edition of Balisage: The Markup Conference.</Description>
      <Stakeholder StakeholderTypeType="Generic_Group">
        <Name>Markup Practitioners</Name>
        <Description>Balisage ~ where serious markup practitioners and theoreticians meet every summer. If you are happy to be the person in your project who understands the angle brackets and stuff, then you are a markup geek and Balisage is the place for you. Even if you are NOT a markup geek, if you find it instructive to spend time with them now and then, you will enjoy Balisage.</Description>
      </Stakeholder>
      <Stakeholder StakeholderTypeType="Generic_Group">
        <Name>Balisage People</Name>
        <Description>People involved with Balisage ~ The people making Balisage include markup theoreticians and practitioners, data modelers, designers, architects, and both aficionados and deep thinkers. We work as software developers, system architects, academics, integrators, librarians, data miners, lexicographers, archivists, document managers, standards developers, programmers, and publishers.</Description>
      </Stakeholder>
      <Stakeholder StakeholderTypeType="Generic_Group">
        <Name>Balisage Conference Committee</Name>
      </Stakeholder>
      <Stakeholder StakeholderTypeType="Person">
        <Name>B. Tommie Usdin</Name>
        <Description>Chair | Mulberry Technologies ~ B. Tommie Usdin is President of Mulberry Technologies, Inc., a consultancy specializing in XML for textual documents. Ms. Usdin has been working with SGML since 1985 and has been a supporter of XML since 1996. She chairs the Balisage conference. Ms. Usdin has developed DTDs, Schemas, and XML/SGML application frameworks for applications in government and industry. Projects include reference materials in medicine, science, engineering, and law; semiconductor documentation; historical and archival materials. Distribution formats have included print books, magazines, and journals, and both web- and media-based electronic publications. She is co-chair of the NISO Z39-96, JATS: Journal Article Tag Suite Working Group and a member of the BITS Working Group and the NISO STS Standing Committee.</Description>
      </Stakeholder>
      <Stakeholder StakeholderTypeType="Person">
        <Name>Deborah A. Lapeyre</Name>
        <Description>Co-Chair | Mulberry Technologies ~ Debbie is a Senior Consultant for Mulberry Technologies, Inc., a consulting firm specializing in helping their clients toward better publishing through XML, XSLT, and Schematron solutions. She works with Tommie Usdin as architects and Secretariat for JATS, NISO STS, and BITS. She has taught hands-on XML, XSLT, DTD and schema construction, and Schematron courses as well as numerous technical and business-level introductions to XML and the JATS family of tag sets.</Description>
      </Stakeholder>
      <Stakeholder StakeholderTypeType="Generic_Group">
        <Name>Balisage Advisory Board</Name>
      </Stakeholder>
      <Stakeholder StakeholderTypeType="Person">
        <Name>Syd Bauman</Name>
        <Description>Northeastern University</Description>
      </Stakeholder>
      <Stakeholder StakeholderTypeType="Person">
        <Name>Jeff Beck</Name>
        <Description>National Library of Medicine</Description>
      </Stakeholder>
      <Stakeholder StakeholderTypeType="Person">
        <Name>David J Birnbaum</Name>
        <Description>University of Pittsburgh</Description>
      </Stakeholder>
      <Stakeholder StakeholderTypeType="Person">
        <Name>Jon Bosak</Name>
      </Stakeholder>
      <Stakeholder StakeholderTypeType="Person">
        <Name>Robin Cover</Name>
        <Description>OASIS</Description>
      </Stakeholder>
      <Stakeholder StakeholderTypeType="Person">
        <Name>Steve DeRose</Name>
        <Description>Independent Consultant</Description>
      </Stakeholder>
      <Stakeholder StakeholderTypeType="Person">
        <Name>Bob DuCharme</Name>
        <Description>CCRi</Description>
      </Stakeholder>
      <Stakeholder StakeholderTypeType="Person">
        <Name>Patrick Durusau</Name>
      </Stakeholder>
      <Stakeholder StakeholderTypeType="Person">
        <Name>Michael Kay</Name>
        <Description>Saxonica</Description>
      </Stakeholder>
      <Stakeholder StakeholderTypeType="Person">
        <Name>Liam Quin</Name>
        <Description>Delightful Computing</Description>
      </Stakeholder>
      <Stakeholder StakeholderTypeType="Person">
        <Name>Norm Tovey-Walsh</Name>
        <Description>Saxonica</Description>
      </Stakeholder>
      <Stakeholder StakeholderTypeType="Person">
        <Name>Ari Nordström</Name>
        <Description>Creative Words</Description>
      </Stakeholder>
      <Stakeholder StakeholderTypeType="Person">
        <Name>Wendell Piez</Name>
        <Description>Piez Consulting Services</Description>
      </Stakeholder>
      <Stakeholder StakeholderTypeType="Generic_Group">
        <Name>Sister/Related Conferences</Name>
      </Stakeholder>
      <Stakeholder StakeholderTypeType="Organization">
        <Name>XML Prague</Name>
      </Stakeholder>
      <Stakeholder StakeholderTypeType="Organization">
        <Name>Markup UK</Name>
      </Stakeholder>
      <Stakeholder StakeholderTypeType="Organization">
        <Name>Mulberry Technologies, Inc.</Name>
        <Description>Conference Producer</Description>
      </Stakeholder>
    </Organization>
    <Vision>
      <Description>There is nothing so practical as a good theory</Description>
      <Identifier>_f3a91b44-7c6e-4e02-a8d5-1c3720fb8e91</Identifier>
    </Vision>
    <Mission>
      <Description>To document and share the agenda for the Balisage 2026 conference, the final edition of Balisage: The Markup Conference.</Description>
      <Identifier>_c82d5f07-2b4a-4c19-9e3a-6d0814b7f2a3</Identifier>
    </Mission>
    <Goal>
      <Name>Day 1 - Monday</Name>
      <Identifier>006596f6-2c96-4a22-8df5-454765e50b58</Identifier>
      <OtherInformation>Monday, August 3, 2026</OtherInformation>
      <Objective>
        <Name>Welcome</Name>
        <Description>Provide conference logistics, tips for attendees, and other getting-started messages</Description>
        <Identifier>ec1b7832-0719-4fd3-8a94-7ff436f83363</Identifier>
        <SequenceIndicator>8-3-09:00</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Generic_Group">
          <Name>Conference Attendees</Name>
        </Stakeholder>
        <OtherInformation>Monday 9:00 - 9:15 EDT | Welcome to Balisage 2026 ~ Conference logistics, tips for attendees, and other getting started messages.</OtherInformation>
      </Objective>
      <Objective>
        <Name>Good Theory (Reflection)</Name>
        <Description>Reflect on the guiding principle of Balisage — &quot;There is nothing so practical as a good theory&quot; — and the mix of case studies, specifications, best practices, and formal models that have shaped the conference over 30 years</Description>
        <Identifier>4d7f76bb-b5f1-46c4-96b8-efd3608271c8</Identifier>
        <SequenceIndicator>8-3-09:15</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>B. Tommie Usdin</Name>
          <Description>Mulberry Technologies</Description>
        </Stakeholder>
        <OtherInformation>Monday 9:15 - 9:45 EDT | There is Nothing So Practical as a Good Theory (Reflection) ~ &quot;There is nothing so practical as a Good Theory&quot; has been the tag line for &quot;Balisage: The Markup Conference&quot; since it started in 2008. With this as the guiding principle behind a conference about markup, Balisage has been a mix of case studies, updates on specifications, tutorials, discussions of best (and sometimes worst) practice, conversations about how things should and/or do work. We have explored markup; tools used to create, manipulate and store marked-up content; markup-related information management principles; and formal and mathematical models of markup. Some of our content is solidly grounded in reality and the practices of daily production of documents, some can best be described as imaginative and fantastical. Each of these realms informs the other, often in unpredictable but rewarding ways.</OtherInformation>
      </Objective>
      <Objective>
        <Name>iXML Notation Design</Name>
        <Description>Use iXML to design a textual representation for XML document types, enabling complex documents to be produced through gradual composition of components</Description>
        <Identifier>523e260a-d872-4574-8956-a8753c9488ad</Identifier>
        <SequenceIndicator>8-3-09:45</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Steven Pemberton</Name>
          <Description>CWI, Amsterdam</Description>
        </Stakeholder>
        <OtherInformation>Monday 9:45 - 10:15 EDT (+ Q&amp;A 10:15 - 10:30) | Designing a Notation Using ixml ~ The ixml language was originally designed to allow un-marked-up textual documents to be treated as if they were XML documents with markup. Although the original intent of ixml was to allow text documents to be treated as XML and then further processed using XML tools, it is possible to work in the other direction: if you have an XML document type, you can use ixml to design a textual representation for it. Take, for example, XForms embedded in an HTML document. Each of the components is well defined, so corresponding text can be developed, with appropriate ixml rules to generate the corresponding output. With a gradual approach to components, even complex documents can be produced.</OtherInformation>
      </Objective>
      <Objective>
        <Name>Track Changes in ContentXML</Name>
        <Description>Manage tracked deletions and insertions across XML tree slices and anchors during automated regex-based global text replacement in the Typefi Orion platform</Description>
        <Identifier>127d27f7-9eae-4773-a9c5-d83286bdea4d</Identifier>
        <SequenceIndicator>8-3-10:45</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Gayanthika Udeshani</Name>
          <Description>Typefi Systems</Description>
        </Stakeholder>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Caleb Clauset</Name>
          <Description>Typefi Systems</Description>
        </Stakeholder>
        <OtherInformation>Monday 10:45 - 11:15 EDT (+ Q&amp;A 11:15 - 11:30) | Track Changes Support for Automated Regex-Based Text Replacement in ContentXML ~ Preserving the editorial history of a document recording who changed what, when — is a staple requirement in many environments. Under the hood, tracked deletions and insertions require one to slice XML trees and insert anchors. What happens when you need to apply global changes to such a file, across and inside slices and anchors? When the replacements have been applied, the new round of changes need to be integrated into the editorial history, and there must be a fair accounting of whether the changes were made to the original text or to one of the insertions. We will take a look at the track changes architecture of Orion Smart Replace, a plugin for the Typefi publishing platform, and in its three-phase operation — unwrap, replace, rewrap — we will consider the technical challenges involved in managing character offsets and nesting tracked changes.</OtherInformation>
      </Objective>
      <Objective>
        <Name>Ebook Backlist Migration</Name>
        <Description>Convert EPUB 2.0 ebook backlists directly to EPUB 3.0 using XProc and the transpect framework to achieve European Accessibility Act compliance</Description>
        <Identifier>3dfc4af4-fa80-4fda-a26a-85329c7c600b</Identifier>
        <SequenceIndicator>8-3-11:30</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Martin Kraetke</Name>
          <Description>le-tex publishing services GmbH</Description>
        </Stakeholder>
        <OtherInformation>Monday 11:30 - 12:00 EDT (+ Q&amp;A 12:00 - 12:15) | E-Book Backlists in, Accessibility out? ~ Since the ratification of the European Accessibility Act (EAA) in 2024, many publishers are sitting on a ticking time bomb: their ebook backlists. There are real issues in the gap between past production standards and the new legal requirements. Can XML transformation help? Not as much as you would think. Even when HTML files of the ebook are available, converting them into XML is not straightforward. My breakthrough thought was that transforming an EPUB 2.0 directly into EPUB 3.0 would be far easier than attempting to use XML as a transitional format. While there are some real limitations, XProc and the XML framework transpect seem to be good tools to orchestrate the unpacking and repacking of EPUBs and manage the mix of XML and binary files, file references, links, and all the other components involved. The software library repub is designed to address issues in outdated ebook formats. While repub cannot eliminate every barrier, it helps improve compliance and increases the likelihood that an ebook will pass accessibility validation. Over 10,000 ebooks have been converted with repub in the past few months. Success!</OtherInformation>
      </Objective>
      <Objective>
        <Name>Taming CSS Debug XML</Name>
        <Description>Use XSLT and SaxonJS to generate scalable reports that tame Antenna House Formatter&apos;s verbose CSS Debug XML output for documents of varying size</Description>
        <Identifier>0384c86c-49ee-4be9-8a35-b9bb2cdb7f24</Identifier>
        <SequenceIndicator>8-3-13:30</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Tony Graham</Name>
          <Description>Antenna House</Description>
        </Stakeholder>
        <OtherInformation>Monday 13:30 - 14:00 EDT | Taming Antenna House Formatter &apos;CSS Debug XML&apos; (Sponsor Presentation) ~ When you use CSS styles with Antenna House Formatter, its &apos;CSS Debug XML&apos; output option makes explicit the value of every CSS property on every element, which CSS rule specified the property, why that rule had precedence, and which line in which file the rule is on. For better or worse, that&apos;s a lot of information, especially for a large document that has many, large CSS stylesheets. The CSS Debug XML can be more that 50x the size of the source HTML or XML. This talk covers the variety of ways that XSLT and SaxonJS are used to generate reports suitable to different sizes of documents that tame the CSS Debug XML and make its information understandable.</OtherInformation>
      </Objective>
      <Objective>
        <Name>XSpec for XProc</Name>
        <Description>Write test suites for XProc pipelines using the XSpec vocabulary to ensure capability and long-term stability</Description>
        <Identifier>7caa249b-23e6-454e-9e71-b2a848c66726</Identifier>
        <SequenceIndicator>8-3-14:00</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Amanda Galtman</Name>
        </Stakeholder>
        <OtherInformation>Monday 14:00 - 14:30 EDT (+ Q&amp;A 14:30 - 14:45) | XSpec for XProc, and XProc for XSLT ~ You set out to build a software pipeline to do important, complex tasks. You want your pipeline to be capable and sturdy over the long haul, and you don&apos;t want to chase bugs constantly or have them chase you. In cases like this, proactive testing is not a luxury but a requirement. XML&apos;s premier pipeline language, XProc, has finally converged with XML&apos;s premier testing language, XSpec. We will see how to write test suites for XProc using the XSpec vocabulary. As the pipeline steps are checked, we&apos;ll also peek into the way processors behave and discover how to leverage their features.</OtherInformation>
      </Objective>
      <Objective>
        <Name>Women Writers Project</Name>
        <Description>Explore the co-evolution of markup practices and publication toolsets across nearly 40 years of the Women Writers Project, examining how markup responds to changing tools and technologies</Description>
        <Identifier>5183d28a-6b1e-4932-9129-fff16f5bd818</Identifier>
        <SequenceIndicator>8-3-14:45</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Julia Flanders</Name>
          <Description>Northeastern University</Description>
        </Stakeholder>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Ash Clark</Name>
          <Description>Northeastern University</Description>
        </Stakeholder>
        <OtherInformation>Monday 14:45 - 15:15 EDT (+ Q&amp;A 15:15 - 15:30) | Synthesis and Sustainability: The Evolution of Markup and Toolsets in the Women Writers Project ~ In 1988, the Women Writers Project (WWP) started working with markup systems. In 1999, the WWP began working with XML publication tools. In both cases, markup and tools, the WWP has treated the work as active research: not only seeking to build a stable, sustainable working system, but also keeping pace with new developments and exploring their implications for research on early women&apos;s writing. The intertwined history and co-evolution of these two sets of practices within the WWP&apos;s nearly 40 years contributes a valuable perspective on scholarly markup in the humanities. We explore the evolution of the WWP&apos;s markup and publication systems. We consider the reciprocal pressure that tools and markup exert on each other, and the ways in which markup responds to changing tools and technologies.</OtherInformation>
      </Objective>
      <Objective>
        <Name>NCBI Bookshelf Validation Pipeline</Name>
        <Description>Implement a validation-driven automation framework for scalable ingestion and processing of biomedical content across a federated architecture at NCBI Bookshelf</Description>
        <Identifier>59cd8a98-cee4-4f3e-8843-ba6e4dc28bd9</Identifier>
        <SequenceIndicator>8-3-15:45</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Kin Ng</Name>
          <Description>National Center for Biotechnology Information, National Library of Medicine, National Institutes of Health</Description>
        </Stakeholder>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Lisandro Gonzalez</Name>
          <Description>National Center for Biotechnology Information, National Library of Medicine, National Institutes of Health</Description>
        </Stakeholder>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Stacy Lathrop</Name>
          <Description>National Center for Biotechnology Information, National Library of Medicine, National Institutes of Health</Description>
        </Stakeholder>
        <OtherInformation>Monday 15:45 - 16:15 EDT (+ Q&amp;A 16:15 - 16:30) | Validation-Driven Automation in a Federated XML Ingest Pipeline: The NCBI Bookshelf Case ~ The NCBI Bookshelf of the National Library of Medicine ingests and makes publicly accessible biomedical books and reports from a variety of sources in many formats and of varying quality. Ensuring data integrity across this content has required substantial manual intervention. We have designed and implemented a validation-driven automation framework for Bookshelf that supports scalable conversion, ingestion, processing, and release of content within a federated architecture. The system integrates rule-based validation, workflow orchestration, and identifier-based reconciliation across multiple systems, including content management, XML processing pipelines, PubMed indexing, and Open Access dataset services. To fix dirty and inconsistent data, we use layered validation (applied at multiple stages in the lifecycle), including Schematron and business-rule enforcement. The pipeline supports multiple conversion and ingestion pathways, including direct XML submission, PDF-to-XML conversion via tagging vendors, and Word-based authoring workflows. These workflows converge on a common processing model governed by validation rules and state transitions tracked in an external workflow system. Validation serves not only as a quality assurance mechanism but as a central organizing principle for workflow automation.</OtherInformation>
      </Objective>
      <Objective>
        <Name>Archive Interactive XQuery</Name>
        <Description>Provide web-based and Jupyter Notebook interfaces over a BaseX interactive XQuery environment enabling scholars to query a 5.5-million-article XML archive of scholarly journal content</Description>
        <Identifier>8c2422c3-dc1a-4b19-92a3-2199dc127403</Identifier>
        <SequenceIndicator>8-3-16:30</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Vincent M. Lizzi</Name>
          <Description>Taylor &amp; Francis</Description>
        </Stakeholder>
        <OtherInformation>Monday 16:30 - 17:00 EDT (+ Q&amp;A 17:00 - 17:15) | Unlocking an Archive of Scholarly Journal Articles with Interactive XQuery (LB (late-breaking)) ~ A BaseX interactive XQuery environment is used to access and query a content archive of more than 5.5 million scholarly journal articles stored in a variety of XML formats. The BaseX database records metadata for each document (dual metadata if needed for different use cases), supporting fast index-based retrieval and synchronization with the content repository. The database offers two complementary interactive user interfaces: web-based and Jupyter Notebook. The web-based interface provides everything from simple document retrieval (by identifier such as DOI or filename) through complex queries across the corpus, including the ability to extract specific portions of selected documents. Available web features include predefined reports, on-screen help, and status monitoring, while also enforcing security restrictions on user-provided XQuery. The Jupyter Notebook interface uses a custom Jupyter Kernel which parallels the functionality of the web interface and enables iterative workflows for data exploration that can provide text, code, and output integrated in a single document. I describe successful design decisions and lessons learned that may benefit others implementing similar XML database solutions.</OtherInformation>
      </Objective>
      <Objective>
        <Name>BoF Session(s)</Name>
        <Description>Choose topics to discuss and keep the conversation(s) on topic</Description>
        <Identifier>06a1161e-2980-4923-bb8a-db8b5a702850</Identifier>
        <SequenceIndicator>8-3-17:15</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Generic_Group">
          <Name>TBA</Name>
          <Description>Discussion Leader(s) to be Announced</Description>
        </Stakeholder>
        <OtherInformation>Monday 17:15… | Birds of a Feather Discussion(s) ~ BoFs are meetings, or mini-meetings, devoted to a topic of interest. See the BOF page to request a BoF and the conference portal for the BoF schedule.</OtherInformation>
      </Objective>
    </Goal>
    <Goal>
      <Name>Day 2 - Tuesday</Name>
      <Identifier>b03b0b49-4a33-48e3-b085-e608974238be</Identifier>
      <OtherInformation>Tuesday, August 4, 2026</OtherInformation>
      <Objective>
        <Name>BoF Session(s)</Name>
        <Description>Choose topics to discuss and keep the conversation(s) on topic</Description>
        <Identifier>8193ca96-014c-4a6f-bac3-edbbdf97b885</Identifier>
        <SequenceIndicator>8-4-08:00</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Generic_Group">
          <Name>TBA</Name>
          <Description>Discussion Leader(s) to be Announced</Description>
        </Stakeholder>
        <OtherInformation>Tuesday 8:00 - 9:00 EDT | Birds of a Feather Discussion(s) ~ BoFs are meetings, or mini-meetings, devoted to a topic of interest. See the BOF page to request a BoF and the conference portal for the BoF schedule.</OtherInformation>
      </Objective>
      <Objective>
        <Name>XSLT/XPath/XQuery 4.0 (Reflection)</Name>
        <Description>Provide a high-level perspective on versions 4.0 of XSLT, XPath, and XQuery — their major innovations, the long journey from 1.0, and the place of the XML terrain within the shifting landscape of standards, implementers, and users</Description>
        <Identifier>85576006-89ef-4d9b-9247-ad011f6edbee</Identifier>
        <SequenceIndicator>8-4-09:00</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Michael Kay</Name>
          <Description>Saxonica</Description>
        </Stakeholder>
        <OtherInformation>Tuesday 9:00 - 9:30 EDT (+ Q&amp;A 9:30 - 9:45) | The XSLT/XPath/XQuery 4.0 Standards: a High-Level Perspective (Reflection) ~ Versions 4.0 of XSLT, XPath, and XQuery are well advanced, and they promise clear advantages for developers. What is the big picture? Not simply new concepts such as JNodes and records, and dozens of new functions — although these are significant — but the place of 4.0 in a long journey that began with 1.0. Even that journey needs to be seen in a wider view, against the backdrop of what standards are, who backs them, who changes them, who implements them, who uses them, and to what end. Reflect, not only on the major changes that 4.0 promises to brings to the XML terrain, but on the place of that XML terrain within the shifting plate tectonics of our day.</OtherInformation>
      </Objective>
      <Objective>
        <Name>Open Mike</Name>
        <Identifier>0adb4171-2976-4509-a6c5-8a073d023ef7</Identifier>
        <SequenceIndicator>8-4-09:45</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Generic_Group">
          <Name>Conference Participants</Name>
        </Stakeholder>
        <OtherInformation>Tuesday 9:45 - 10:30 EDT | Open Mike: Anything Goes ~ Balisage short subject open microphone. All conference participants are invited to give a 2 to 10 minute presentation on ANY topic (within the limits of the conference Code of Conduct). Use video, sound, bullet point slides, cartoons, visualizations, SW demonstrations, or just yourself as a talking head. Anything goes!</OtherInformation>
      </Objective>
      <Objective>
        <Name>Transcriptional Implicature</Name>
        <Description>Develop a formal account of transcriptional implicature — the shared community assumptions underlying transcription practice — to explain both common patterns and variations across scholarly editions</Description>
        <Identifier>79844bf4-76f7-494c-ad38-6847763e3263</Identifier>
        <SequenceIndicator>8-4-10:45</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>C. M. Sperberg-McQueen</Name>
          <Description>Black Mesa Technologies LLC</Description>
        </Stakeholder>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Claus Huitfeldt</Name>
          <Description>University of Bergen</Description>
        </Stakeholder>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Yves Marcoux</Name>
          <Description>École de bibliothéconomie et des sciences de l&apos;information, Université de Montréal</Description>
        </Stakeholder>
        <OtherInformation>Tuesday 10:45 - 11:15 EDT (+ Q&amp;A 11:15 - 11:30) | Transcriptional implicature ~ Many people transcribe many materials in many ways; universal transcription practice is elusive: for every generalization we find exceptions. Is everything in the exemplar transcribed? Not necessarily. Does everything in the transcript reproduce some word or character in the exemplar? Not necessarily. Many scholarly editions account for transcription variations in an explicit statement of transcription practice. Such statements typically describe deviations from the usual practice, but rarely the ways in which it exemplifies usual practice. By transcriptional implicature for a given community, we mean the things, suggested or entailed by the rules of transcription, that members of that community may find unnecessary to mention explicitly. We propose a way of accounting for common practices while also making sense of variations in practice and sketch a formal approach to transcription in hopes that it will inspire future work.</OtherInformation>
      </Objective>
      <Objective>
        <Name>Next-gen Markup Parsing</Name>
        <Description>Apply iXML-like processing using mildly context-sensitive grammars to interpret and explicitly tag next-generation markup features — overlap, discontinuity, and related structures — that XML was not designed to represent</Description>
        <Identifier>899810de-c1cf-4ac3-9f29-b566ec303b69</Identifier>
        <SequenceIndicator>8-4-11:30</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Ronald Haentjens Dekker</Name>
          <Description>DHLab and Huygens Institute, Royal Netherlands Academy of Sciences</Description>
        </Stakeholder>
        <Stakeholder StakeholderTypeType="Person">
          <Name>David J. Birnbaum</Name>
          <Description>University of Pittsburgh</Description>
        </Stakeholder>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Bram Buitendijk</Name>
          <Description>KNAW Humanities Cluster</Description>
        </Stakeholder>
        <OtherInformation>Tuesday 11:30 - 12:00 EDT (+ Q&amp;A 12:00 - 12:15) | On beyond Invisible XML: parsing with implicit (and explicit) next-generation markup ~ We explore what Invisible-XML-like (ixml-like) processing might look like when applied to what we refer to as &quot;next-generation features&quot; of markup: structural properties of textual documents that XML was not designed to represent, such as overlap, discontinuity, and others. This ixml-like approach is intended to interpret implicit, untagged markup and express it with explicit markup. These features may be implicit within a document, or explicitly tagged using markup languages such as LMNL, TexMECS, and TagML. We identify two approaches to ixml-like processing of next-generation features using mildly context-sensitive grammars to overcome the limitations of context-free grammars.</OtherInformation>
      </Objective>
      <Objective>
        <Name>Semantic XML for Document AI</Name>
        <Description>Introduce DGML (Document Graph Markup Language), a semantic XML representation of business documents offering cross-document tag consistency, spatial grounding, and cryptographic attestation for enterprise document AI</Description>
        <Identifier>588c99e0-14c1-4614-9a31-b3fddb7c5a02</Identifier>
        <SequenceIndicator>8-4-13:30</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Jean Paoli</Name>
          <Description>Docugami</Description>
        </Stakeholder>
        <OtherInformation>Tuesday 13:30 - 14:00 EDT | Semantic XML for the Age of Document AI (Sponsor Presentation) ~ DGML — Document Graph Markup Language — is a semantic XML representation of business documents. Docugami, with Inveniam, is opening the format itself to the industry as a potential standard, together with a reference open-source implementation. Where raw extraction gives you fields, and structural markup gives you shape, DGML gives you meaning: tags that describe what each element is in its domain — a liability cap, an effective date, a payment obligation — not how it appeared on the page. DGML&apos;s headline property is cross-document tag consistency: a stable vocabulary across every document of a given type, making a corpus queryable without per-document prompt engineering. A four-layer architecture — semantic tagging, spatial grounding via pixel bounding boxes, cryptographic fragment-level attestation, and browser-native readability — makes DGML suitable for enterprise document AI: economical enough for an agent to process, and provable enough for its answer to be trusted. This paper introduces the format, its schema mechanism, and its packaging.</OtherInformation>
      </Objective>
      <Objective>
        <Name>Host-Language Extension Functions</Name>
        <Description>Benchmark host-language extension functions written in Java, C++, and Python against equivalent XSLT, XQuery, and XPath logic to examine trade-offs between declarative purity, execution performance, and integration flexibility</Description>
        <Identifier>670d95c7-f756-4592-9c18-b51a83ed807f</Identifier>
        <SequenceIndicator>8-4-14:00</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>O&apos;Neil Delpratt</Name>
          <Description>Saxonica</Description>
        </Stakeholder>
        <OtherInformation>Tuesday 14:00 - 14:30 EDT (+ Q&amp;A 14:30 - 14:45) | Achieving Near-Native Performance in XSLT, XQuery, and XPath Using Host-Language User Extension Functions (LB (late-breaking)) ~ When might you reach for an extension function written in C++ over its equivalent XPath function? This paper investigates the performance and practical benefits of using host-language extension functions where necessary as an alternative to implementing equivalent logic directly in XSLT, XQuery, or XPath. As a case study, we implement and benchmark equivalent computational workloads using extension functions written in Java, C++, Python. We examine the trade-offs between declarative purity, execution performance, and integration flexibility, including the overhead of crossing language boundaries and the circumstances under which host-language implementations can outperform equivalent XML-language expressions.</OtherInformation>
      </Objective>
      <Objective>
        <Name>XML Document Complexity</Name>
        <Description>Develop holistic approaches for quantifying and understanding operational complexity in XML documents from the perspective of XML users</Description>
        <Identifier>b9828507-5b10-4605-8b54-cd7b2891e165</Identifier>
        <SequenceIndicator>8-4-14:45</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Sarah Connell</Name>
          <Description>Northeastern University / Library / DSG / WWP</Description>
        </Stakeholder>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Syd Bauman</Name>
          <Description>Northeastern University / Library / DSG / WWP</Description>
        </Stakeholder>
        <OtherInformation>Tuesday 14:45 - 15:15 EDT (+ Q&amp;A 15:15 - 15:30) | It&apos;s Complicated: Holistic Approaches for Considering Complexity in XML Documents ~ &quot;Complex&quot;: adjective. (1) Composed of two or more parts. (2) Hard to separate, analyze, or solve. What does &quot;complex&quot; mean, in practice? If you and I agree that one XML file is more complex than another, upon what basis do we agree, and can that be quantified? Are the parts I see as significant the same ones you see as significant? How much weight should be given to hierarchical depth versus the number of siblings versus the type and content of attributes? And how do we even start to fit namespaces into that equation? But mere counting oversimplifies a problem that is rooted in operational complexity, a quality that can be understood only from the perspective of XML users.</OtherInformation>
      </Objective>
      <Objective>
        <Name>MVG: Graceful SVG Diagramming</Name>
        <Description>Use MVG (Meta Vector Graphics), layered over SVG, to treat drawing objects with XML-familiar structure and semantic organization while producing plain SVG compatible with existing tools</Description>
        <Identifier>735b4262-850c-4f72-9402-c1c2e1ce41b1</Identifier>
        <SequenceIndicator>8-4-15:45</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Steven J. DeRose</Name>
        </Stakeholder>
        <OtherInformation>Tuesday 15:45 - 16:15 EDT (+ Q&amp;A 16:15 - 16:30) | Graceful Diagramming with SVG plus AVTs ~ SVG is a mature, reliable XML vocabulary for vector graphics, but it is very unlike other XML applications because it lacks semantic structure and the ability to bind components into logical units. MVG (Meta Vector Graphics), an extension layered over SVG, treats drawing objects more like XML users expect, while still producing plain SVG that is compatible with existing tools. In addition to giving structure to SVG, MVG offers a repertoire of familiar geometric primitives. MVG&apos;s additions should be highly intuitive to users of XML, XSLT, and SVG, because they reuse notions that are well known and provide a declarative, user-oriented way to construct drawings.</OtherInformation>
      </Objective>
      <Objective>
        <Name>Holons and Markup (Reflection)</Name>
        <Description>Trace a personal journey through XML, XSLT, XSD, XQuery, RDF, SHACL, and neural systems, arriving at the holonic graph as the resolution of a tension implicit in markup and semantic web design — and now made explicit through RDF 1.2, SHACL 1.2, and named graphs</Description>
        <Identifier>ef27b303-814d-425a-b74b-b031fc767cdd</Identifier>
        <SequenceIndicator>8-4-16:30</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Kurt Cagle</Name>
        </Stakeholder>
        <OtherInformation>Tuesday 16:30 - 17:00 EDT (+ Q&amp;A 17:00 - 17:15) | From XML to Holons (Reflection) ~ Thirty years of working with markup languages, semantic web standards, and knowledge representation systems has revealed a single recurring problem wearing many different masks: the problem of bounded, scoped, composable meaning. I describe my personal and technical journey from the HTML Document Object Model of 1996 through XML, XSLT, XSD, XQuery, RDF, SHACL, and the neural systems of the present day, arriving at the holonic graph as the resolution of a tension that has persisted, largely unacknowledged, throughout the life of the markup community. The holon — Arthur Koestler&apos;s term for a unit that is simultaneously a whole and a part of a larger whole — turns out to have been implicit in every major design decision underlying XML and the semantic web. RDF 1.2, SHACL 1.2, and named graphs now provide the formal apparatus to make this reliance on holons explicit. The implications extend from knowledge governance to the grounding of large language models.</OtherInformation>
      </Objective>
      <Objective>
        <Name>BoF Session(s)</Name>
        <Description>Choose topics to discuss and keep the conversation(s) on topic</Description>
        <Identifier>9877eb55-3a85-4239-a816-4cea2d47d1c4</Identifier>
        <SequenceIndicator>8-4-17:15</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Generic_Group">
          <Name>TBA</Name>
          <Description>Discussion Leader(s) to be Announced</Description>
        </Stakeholder>
        <OtherInformation>Tuesday 17:15… | Birds of a Feather Discussion(s) ~ BoFs are meetings, or mini-meetings, devoted to a topic of interest. See the BOF page to request a BoF and the conference portal for the BoF schedule.</OtherInformation>
      </Objective>
    </Goal>
    <Goal>
      <Name>Day 3 - Wednesday</Name>
      <Identifier>a0f3f084-885e-4f9a-80a1-4f7c67773bea</Identifier>
      <OtherInformation>Wednesday, August 5, 2026</OtherInformation>
      <Objective>
        <Name>BoF Session(s)</Name>
        <Description>Choose topics to discuss and keep the conversation(s) on topic</Description>
        <Identifier>01efdc6e-f445-431b-b6e0-0644cabdd13a</Identifier>
        <SequenceIndicator>8-5-08:00</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Generic_Group">
          <Name>TBA</Name>
          <Description>Discussion Leader(s) to be Announced</Description>
        </Stakeholder>
        <OtherInformation>Wednesday 8:00 - 9:00 EDT | Birds of a Feather Discussion(s) ~ BoFs are meetings, or mini-meetings, devoted to a topic of interest. See the BOF page to request a BoF and the conference portal for the BoF schedule.</OtherInformation>
      </Objective>
      <Objective>
        <Name>EPUB and OOXML Schema Roles</Name>
        <Description>Compare how XML schemas function as sanity-checking validation artifacts in the EPUB ecosystem versus documentation artifacts guiding developer interoperability in the OOXML ecosystem</Description>
        <Identifier>c886f89e-5b63-433a-8411-2fe15c98883d</Identifier>
        <SequenceIndicator>8-5-09:00</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Makoto MURATA</Name>
          <Description>Higashi Nippon International University &amp; Information Accessibility Institute, LLC</Description>
        </Stakeholder>
        <OtherInformation>Wednesday 9:00 - 9:30 EDT (+ Q&amp;A 9:30 - 9:45) | Schemas in EPUB and OOXML: Sanity Checking versus Documentation ~ XML schemas perform two significantly different functions: sanity checking and documentation. By comparing the roles of the schema in EPUB and Office Open XML (OOXML) we show how these differ by ecosystem. In the EPUB ecosystem, schemas serve primarily as validation artifacts to ensure content quality throughout the distribution pipeline. In contrast, the OOXML ecosystem lacks mandatory validation during distribution. However, a validation experiment suggests that third-party office suites produce nearly valid XML once Markup Compatibility Elements (MCE) are preprocessed. This demonstrates that OOXML schemas function successfully as documentation artifacts, guiding developers in software quality assurance to achieve interoperability.</OtherInformation>
      </Objective>
      <Objective>
        <Name>Distributed Text Services 1.0</Name>
        <Description>Publish and extend TEI document collections through the DTS 1.0 API standard, making documents findable, accessible, interoperable, and reusable for both human and machine clients</Description>
        <Identifier>5616a79a-4750-4b00-aae4-f5f7bc72f01b</Identifier>
        <SequenceIndicator>8-5-09:45</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Thibault Clérice</Name>
          <Description>Institut national de recherche en sciences &amp; technologies du numérique</Description>
        </Stakeholder>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Hugh Cayless</Name>
          <Description>Duke University</Description>
        </Stakeholder>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Jonathan Robie</Name>
        </Stakeholder>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Ian Scott</Name>
          <Description>Knowledge Commons, Michigan State University</Description>
        </Stakeholder>
        <OtherInformation>Wednesday 9:45 - 10:15 EDT (+ Q&amp;A 10:15 - 10:30) | Distributed Text Services 1.0: An API Standard for Publishing and Extending TEI Document Collections ~ After pouring thousands of hours into marking up collections of documents, many of us face a whole new set of challenges when we are finally ready to share our work. How do we go beyond simply publishing the text for human readers? The first stable release of the Distributed Text Services (DTS) specification offers a blueprint: expose collections of documents through a flexible set of API endpoints, to human and machine clients alike. Though our corpora may differ substantially, we can make our documents findable, accessible, interoperable, and reusable (FAIR) by implementing the DTS 1.0 specification in our own APIs. Beyond making collections FAIR, DTS 1.0 implementers can make complex document structures more readily accessible.</OtherInformation>
      </Objective>
      <Objective>
        <Name>Complex XProc Validation</Name>
        <Description>Implement enterprise middleware as a single XProc pipeline with MorganaXProc-III to serve as a quality gatekeeper for XML-first publishing workflows, refining validity criteria through postprocessing of validation reports</Description>
        <Identifier>1f1fae85-1239-4181-abee-590378aa25d8</Identifier>
        <SequenceIndicator>8-5-10:45</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Andrew Sales</Name>
          <Description>Bloomsbury Publishing Group plc</Description>
        </Stakeholder>
        <OtherInformation>Wednesday 10:45 - 11:15 EDT (+ Q&amp;A 11:15 - 11:30) | Beyond valid and invalid: implementing complex validation in XProc ~ Bloomsbury Publishing Group plc began as a trade publisher nearly forty years ago, now with an academic division. Our digital products include Bloomsbury Collections (c. 50,000 academic monographs), Drama Online (home of the Arden Shakespeare) and the Churchill Archive (the complete digitized papers of Sir Winston Churchill, 800,000+). We publish around 3,500 titles per year on the academic list. Our team&apos;s main responsibility is to &quot;spec and check&quot;. We specify documentation requirements, maintain content conversion documentation, and support validation assets. This documentation is used by our supplier base to prepare the XML used to publish online content and to apply quality assurance prior to publication. This paper describes the (re-)implementation of a piece of enterprise middleware that acts as quality gatekeeper for our XML-first publishing workflow. We describe how we refactor equivalent legacy software as a single XProc pipeline with MorganaXProc-III; how we test this pipeline; and how we use the postprocessing of the validation reports it produces to both refine and redefine our validity criteria, based on the &quot;size and shape&quot; of the documents under scrutiny and the extent to which they violate our business rules.</OtherInformation>
      </Objective>
      <Objective>
        <Name>Abstraction and Paradox</Name>
        <Description>Examine how increasing levels of abstraction in computing and information science — from relational databases to declarative markup to ontologies — lead to contradiction, ambiguity, and paradox, with serious consequences in automated digital environments</Description>
        <Identifier>da8303ba-ff04-4a34-aece-8429a74d13d4</Identifier>
        <SequenceIndicator>8-5-11:30</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Allen H. Renear</Name>
          <Description>School of Information Sciences, University of Illinois Urbana-Champaign</Description>
        </Stakeholder>
        <OtherInformation>Wednesday 11:30 - 12:00 EDT (+ Q&amp;A 12:00 - 12:15) | Abstraction, Paradox, and the End of History ~ In computing and information science, abstraction plays a leading role in how we tell the story of the evolution of programming languages, software engineering, data management systems, and document text encoding. For example, we can represent data as columns and tables in a relational database, &quot;abstracting away&quot; physical storage concerns; or we can mark up a document according to its semantics rather than how it will be processed. With ontologies and conceptual models at yet higher levels of abstraction, it may seem that we have now reached the zenith of abstraction and are ready to enjoy the benefits of a perfect match between human understanding and our digital information systems. However, scientific and philosophic traditions have shown that greater abstraction leads to contradiction, ambiguity, and resulting paradoxes. In an automated digital environment, a failure in abstract reasoning can occur without human oversight, with serious consequences.</OtherInformation>
      </Objective>
      <Objective>
        <Name>Typefi Orion</Name>
        <Description>Introduce Typefi Orion, a replacement editorial tool for the discontinued Inera eXtyles, built to match and extend its JATS, BITS, and STS XML authoring and editorial capabilities for scholarly publishing</Description>
        <Identifier>e24a52fe-28ff-4b52-b63b-6f97e2cb0a23</Identifier>
        <SequenceIndicator>8-5-13:30</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Guy van der Kolk</Name>
          <Description>Typefi</Description>
        </Stakeholder>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Lukas Kaefer</Name>
          <Description>Typefi</Description>
        </Stakeholder>
        <OtherInformation>Wednesday 13:30 - 14:00 EDT | Typefi Orion: The future of JATS, BITS, and STS editorial tools (Sponsor Presentation) ~ In the world of scholarly publishing, Inera eXtyles has long been the XML editorial standard. This legendary software suite is a Microsoft Word Add-in that automates the most tedious parts of editorial work (cleanup, styling, reference checking, etc.) and enables exporting JATS, BITS, and STS XML directly from Microsoft Word — but support for it ends this August. When Typefi heard about the impending end of eXtyles, the team immediately set to work building a replacement called Typefi Orion. Over 16 months of intense development, the team iterated and tested almost constantly, met monthly with eXtyles users to get input and feedback, enlisted editorial experts like Robin Dunford, and travelled to events around the world to introduce Orion and get more input from the community. Typefi Orion matches all the core features and functions of eXtyles, along with significant enhancements based on feedback from real editors. It&apos;s the most robust XML authoring and editorial software for scholarly publishing on the market today.</OtherInformation>
      </Objective>
      <Objective>
        <Name>Schematron Batch Fixes</Name>
        <Description>Re-engineer DIN&apos;s Schematron Batch Fixes normalization process with a layered, extensible Schematron mechanism orchestrated by an XProc pipeline, to normalize heterogeneous NISO STS standards content from multiple standards bodies</Description>
        <Identifier>e71fa440-0ec0-4e62-a6e9-a4647b1ecd0b</Identifier>
        <SequenceIndicator>8-5-14:00</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Gerrit Imsieke</Name>
          <Description>le-tex publishing services GmbH</Description>
        </Stakeholder>
        <OtherInformation>Wednesday 14:00 - 14:30 EDT (+ Q&amp;A 14:30 - 14:45) | Schematron Batch Fixes (LB (late-breaking)) ~ Many international standards are coded in the tag set NISO STS (NISO Tag Suite) for interchange and processing by standards partners and clients worldwide. By design, NISO STS is an enabling not a prescriptive standard, so even when the Standards Development Organizations (SDOs) all encode using NISO STS, or can convert their preferred tag set to NISO STS, different SDOs employ different conventions on how to mark up and package their standards. Normalizing away all this variability allows DIN to process heterogeneous input from many SDOs into formats and structures that DIN can process. This case study documents an as-yet-unfinished rewrite of the batch normalization process (Schematron Batch Fixes or SBF) used by DIN for this normalization. SBF relies on the ideas of Schematron Quick Fix but applied to batches of documents, not interactively one document at a time. The process is orchestrated by an XProc pipeline that can re-run all the checks after all fixes have been applied and report which of the fixes have been successful at which input locations. SBF uses a layered Schematron schema extension mechanism that adds an extending Schematron schema to build on a base schema. The extending schema can add, replace or remove fixes, and specify dependencies among fixes. Thus the correction and checking profile is no longer a single Schematron schema but a collection of Schematron files, with an NVDL (Namespace-based Validation Dispatching Language) bracket around them. The re-engineered SBF will provide validations beyond XML files, such as directory listings, Zip archive contents, and (most excitingly) XProc files.</OtherInformation>
      </Objective>
      <Objective>
        <Name>XML as Technological Pinnacle</Name>
        <Description>Examine why XML has endured as a foundational technology for three decades since emerging from SGML, and what grounds its place in the general history of technological development</Description>
        <Identifier>ed6af788-0565-46d3-8840-5240cc781afe</Identifier>
        <SequenceIndicator>8-5-14:45</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Simon St.Laurent</Name>
        </Stakeholder>
        <OtherInformation>Wednesday 14:45 - 15:15 EDT (+ Q&amp;A 15:15 - 15:30) | XML as a Technological Pinnacle (LB (late-breaking)) (Reflection) ~ Even in times of rapid technological change and advancement, occasionally a technology appears that becomes so foundational that it endures, even while all else around it changes. XML seems to be such a pinnacle technology, having survived some three decades after it emerged from the even older SGML. Come and see what makes XML so resilient, and how its place in the general history of technological development grounds it for future survival.</OtherInformation>
      </Objective>
      <Objective>
        <Name>XPath 4 Generators</Name>
        <Description>Use generators in XPath 4 to enable deferred evaluation and processing of humongous or infinite sequences — such as news feeds and astronomical databases — without loading entire sequences into memory</Description>
        <Identifier>983e15ad-9718-4aa4-a83c-1ff0bc32d8ca</Identifier>
        <SequenceIndicator>8-5-15:45</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Dimitre Novatchev</Name>
        </Stakeholder>
        <OtherInformation>Wednesday 15:45 - 16:15 EDT (+ Q&amp;A 16:15 - 16:30) | Generators – Deferred Evaluation in XPath 4 ~ When processing sequences of a few items, memory and performance are negligible. But when we need to engage in real world data such as news feeds, astronomical databases, or the Fibonacci sequence, we face sequences of items that are humongous or infinite (potentially or actually). Conventional approaches do not work. Generators are designed to address this problem, by allowing developers to get only the data that is needed, without attempting to load into memory the entire sequence. Through a real-world use case of news feed aggregation, we will learn how an XPath-first implementation of generators promises to revolutionize our handling of big data.</OtherInformation>
      </Objective>
      <Objective>
        <Name>WordPress and Declarative Markup (Reflection)</Name>
        <Description>Reflect on what good document-management practices learned in the declarative markup community can contribute to building online archives in a world that has never heard of declarative markup</Description>
        <Identifier>52d9da49-2afe-4aaa-8595-e82fd60e281d</Identifier>
        <SequenceIndicator>8-5-16:30</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Jeffrey Beck</Name>
        </Stakeholder>
        <OtherInformation>Wednesday 16:30 - 17:00 EDT (+ Q&amp;A 17:00 - 17:15) | My Whole Career Was a Lie? Or: How I Learned to Stop Worrying and Love WordPress (Reflection) ~ We in the declarative markup community have long asserted that declarative markup plays a foundational role in modern document processing by separating content from process and presentation. Declarative markup makes content maintainable, reusable, and adaptable across platforms and technologies. But there is another world out there that has never heard of declarative markup, much less seen a need for it. Building an online archive in that environment does not depend on any of the tools we&apos;ve grown used to in our world. What we&apos;ve learned about organization, curation, and other good document-management practices can usefully be carried over into that strange new world.</OtherInformation>
      </Objective>
      <Objective>
        <Name>BoF Session(s)</Name>
        <Description>Choose topics to discuss and keep the conversation(s) on topic</Description>
        <Identifier>f66237a4-198d-4b99-9515-85091ecacdba</Identifier>
        <SequenceIndicator>8-5-17:15</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Generic_Group">
          <Name>TBA</Name>
          <Description>Discussion Leader(s) to be Announced</Description>
        </Stakeholder>
        <OtherInformation>Wednesday 17:15… | Birds of a Feather Discussion(s) ~ BoFs are meetings, or mini-meetings, devoted to a topic of interest. See the BOF page to request a BoF and the conference portal for the BoF schedule.</OtherInformation>
      </Objective>
    </Goal>
    <Goal>
      <Name>Day 4 - Thursday</Name>
      <Identifier>4809aff4-8d77-43ee-9141-1f25d2d790a2</Identifier>
      <OtherInformation>Thursday, August 6, 2026</OtherInformation>
      <Objective>
        <Name>BoF Session(s)</Name>
        <Description>Choose topics to discuss and keep the conversation(s) on topic</Description>
        <Identifier>c15cc3d5-59d3-48f3-83e2-7c72ec575a30</Identifier>
        <SequenceIndicator>8-6-08:00</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Generic_Group">
          <Name>TBA</Name>
          <Description>Discussion Leader(s) to be Announced</Description>
        </Stakeholder>
        <OtherInformation>Thursday 8:00 - 9:00 EDT | Birds of a Feather Discussion(s) ~ BoFs are meetings, or mini-meetings, devoted to a topic of interest. See the BOF page to request a BoF and the conference portal for the BoF schedule.</OtherInformation>
      </Objective>
      <Objective>
        <Name>Bunkankun Distributed Text</Name>
        <Description>Model premodern Chinese texts on the ancient scroll (juan) — an archival format holding normalized text with little metadata, complemented by YAML/Docker-like recipe formats that coordinate sets of archives</Description>
        <Identifier>e372d84e-0d73-455b-b496-0ba653a9655c</Identifier>
        <SequenceIndicator>8-6-09:00</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Christian Wittern</Name>
          <Description>Institute for Research in Humanities, Kyoto University, Japan</Description>
        </Stakeholder>
        <OtherInformation>Thursday 9:00 - 9:30 EDT (+ Q&amp;A 9:30 - 9:45) | Bunkankun: Digital Text as distributed layers (LB (late-breaking)) ~ Markup in XML can be impractical for certain users, and for certain texts. In the case of premodern Chinese texts, TEI has produced mixed results, and alternatives are needed. The notion of the ancient scroll, juan in Chinese, provides a catalyst for a more suitable approach to the markup task, where an archival format, which like the scroll contains the normalized text without space or formatting and little metadata, is complemented by recipe formats that coordinate sets of archives. This approach to markup, conceptually patterned after YAML and Docker recipes, is exactly what has been needed for the markup of premodern Chinese texts.</OtherInformation>
      </Objective>
      <Objective>
        <Name>XML, MCP, and Language Models</Name>
        <Description>Implement a principled separation of concerns between generative AI models and structured XML data by keeping XML accessible through an MCP server enabling XPath queries, rather than folding it into the language model&apos;s internal machinery</Description>
        <Identifier>238427d0-e304-4513-ac28-e0cdb77edf14</Identifier>
        <SequenceIndicator>8-6-09:45</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Elisa E. Beshero-Bondar</Name>
          <Description>Penn State Erie, The Behrend College</Description>
        </Stakeholder>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Michael Roy Simons</Name>
          <Description>Penn State Erie, The Behrend College</Description>
        </Stakeholder>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Molly Scott Wright</Name>
          <Description>Penn State Erie, The Behrend College</Description>
        </Stakeholder>
        <OtherInformation>Thursday 9:45 - 10:15 EDT (+ Q&amp;A 10:15 - 10:30) | XML, MCP, and Language Models: A Separation of Concerns ~ This paper reflects on the &quot;DigitAI&quot; project&apos;s experiments to integrate Small Language Models (SLMs) with XML technologies in academic digital humanities work. The project is motivated by two goals: making &quot;explainable AI&quot; systems that help us understand how language models process, retrieve, and generate text; and making local, customized AI systems as an alternative to economically and environmentally costly Large Language Models. We first attempted to provide an SLM with a Retrieval Augmented Generation (RAG) system built from the TEI P5 Guidelines. This approach proved both bloated and disappointing. We came to realize that XML should be kept as XML, held apart from the language model&apos;s internal machinery, and made accessible instead through a Model Context Protocol (MCP) server that allows the SLM to query the TEI document tree directly using XPath and related technologies. We propose a principled, declarative approach to AI-assisted XML work: a &quot;separation of concerns&quot; between the generative model and the structured data it consults.</OtherInformation>
      </Objective>
      <Objective>
        <Name>TEI Processing Model Interactions</Name>
        <Description>Extend the TEI Processing Model with interactive behaviors — inspired by TEI Publisher — to allow projects to declaratively specify user interactions in generated digital edition sites</Description>
        <Identifier>56f74d82-7dcf-4b98-8c28-617fb57e9e4c</Identifier>
        <SequenceIndicator>8-6-10:45</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Peter Boot</Name>
          <Description>Huygens Institute for the History and Culture of the Netherlands</Description>
        </Stakeholder>
        <OtherInformation>Thursday 10:45 - 11:15 EDT (+ Q&amp;A 11:15 - 11:30) | Extending the TEI Processing Model to Describe Digital Edition Interactions ~ The TEI Processing Model (TEI PM) provides a declarative specification for publishing digital editions, describing a number of behaviours that can be attached to TEI elements. Projects can describe desired rendering of their encoding using these behaviours, which are almost all (currently) static — for example, general textual (structural) behaviours such as paragraph, block, and figure. TEI PM provides no way for a project to describe how the user can interact with a generated site. Digital editions, however, are by nature interactive tools. I discuss a number of issues that arise when defining interactive behaviours and propose a number of new behaviours (experimental, but implemented). Most of the new behaviours are inspired by the interactivity currently available in TEI Publisher, to date the only workable implementation of the TEI PM.</OtherInformation>
      </Objective>
      <Objective>
        <Name>SGML Round-trip Processing</Name>
        <Description>Convert SGML documents to XML for processing using modern tools, then convert them back to SGML, providing a reversible pipeline for holders of mandated SGML libraries</Description>
        <Identifier>a8a1e048-1d60-4cf1-97bd-27f4ef9496c2</Identifier>
        <SequenceIndicator>8-6-11:30</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Ari Nordström</Name>
          <Description>Creative Words</Description>
        </Stakeholder>
        <OtherInformation>Thursday 11:30 - 12:00 EDT (+ Q&amp;A 12:00 - 12:15) | Don&apos;t Touch My SGML ~ SGML may be old and cranky, but there are many users whose libraries of SGML documents are too vast to be given up and whose use of SGML may be mandated. However, SGML tools are rare, especially when compared to XML tools. So what can a holder of SGML documents do? One solution is to convert documents to XML for processing and then convert them back to SGML. A pipeline that starts with James Clark&apos;s SGML tools and passes through multiple XSLT transformations seems to be the best approach and has the advantage of being reversible at the end. The result is that the users get to use modern processing tools while maintaining their valuable libraries.</OtherInformation>
      </Objective>
      <Objective>
        <Name>Open Mike</Name>
        <Identifier>8a8ca107-7763-4d12-b6a5-69819eb197a8</Identifier>
        <SequenceIndicator>8-6-13:30</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Generic_Group">
          <Name>Conference Participants</Name>
        </Stakeholder>
        <OtherInformation>Thursday 13:30 - 14:45 EDT | Open Mike: Anything Goes ~ Balisage short subject open microphone. All conference participants are invited to give a 2 to 10 minute presentation on ANY topic (within the limits of the conference Code of Conduct). Use video, sound, bullet point slides, cartoons, visualizations, SW demonstrations, or just yourself as a talking head. Anything goes!</OtherInformation>
      </Objective>
      <Objective>
        <Name>Vibe Coding an XML Program</Name>
        <Description>Build a schema-disciplined, XML-aware desktop application almost entirely through AI-assisted &quot;vibe coding,&quot; testing whether a two-LLM workflow plus expert review can produce robust software</Description>
        <Identifier>40d738f0-ebe0-4035-b8b3-fdf88fdb7de9</Identifier>
        <SequenceIndicator>8-6-14:45</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Benjamin Wolfe</Name>
          <Description>Wolfshafen Press</Description>
        </Stakeholder>
        <OtherInformation>Thursday 14:45 - 15:15 EDT (+ Q&amp;A 15:15 - 15:30) | Heart of Dorkness - A Journey in Vibe Coding an XML-Aware Program (LB (late-breaking)) ~ Ars Magica is a complex tabletop roleplaying game whose rules and source texts were released under open license in 2024. My software &quot;Hermetic Foundry&quot; is a free, open-source character-creation and saga-management application for Ars Magica. The project began as a modest AI-assisted user-interface prototype, but it became an experiment: could an experienced programmer build a serious XML-aware desktop application by &quot;vibe coding&quot; almost everything through ChatGPT and Codex? The result was surprisingly not chaotic XML. The schema set validated cleanly, used stable identifiers and cross-references, and developed into a package architecture with fixtures and regression validation. I have now tried LLM-assisted XML software development, and I argue that a two-LLM workflow – one refining prose, one implementing code – plus expert review can produce surprisingly robust, schema-disciplined software.</OtherInformation>
      </Objective>
      <Objective>
        <Name>Scholia 2026</Name>
        <Description>Build XProc-based, iXML-enabled tools — including a Laminator that merges overlapping non-XML ranges — to create graded readers and personal annotations supporting learning of ancient languages</Description>
        <Identifier>f18b5e4a-a47f-4119-bb19-615b5e532649</Identifier>
        <SequenceIndicator>8-6-15:45</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Wendell Piez</Name>
        </Stakeholder>
        <OtherInformation>Thursday 15:45 - 16:15 EDT (+ Q&amp;A 16:15 - 16:30) | Scholia 2026: DIY study aids with TEI, XProc, browser and printer ~ Using electronic tools to learn an ancient language might seem obvious. Surprisingly, the best approach may be to build simple tools that imitate classical approaches to language learning. With the availability of online resources (such as digitized ancient texts), we can build tools like graded readers that enable learning by encouraging the student to create new translations and personal annotations rather than providing existing translations and annotations. The author has built a number of tools. One of these, the Laminator, is an XProc-based, iXML-enabled processing stack. It manages and merges a markup notation designed to represent a text, not as a structure of (XML) elements, but as a set of (not-XML) ranges, including overlapping ranges. More tools are evolving as the author extends his studies.</OtherInformation>
      </Objective>
      <Objective>
        <Name>Zettelkasten and Topic Maps</Name>
        <Description>Develop a framework — drawing on information theory, cognitive science, human interface, movie production practice, data modeling, and library science — to understand how Zettelkasten-style systems can achieve Luhmann-level serendipity and thinking support</Description>
        <Identifier>95b54eb7-99ed-4556-b8fe-41486493f587</Identifier>
        <SequenceIndicator>8-6-16:30</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Thomas B. Passin</Name>
        </Stakeholder>
        <OtherInformation>Thursday 16:30 - 17:00 EDT (+ Q&amp;A 17:00 - 17:15) | The Zettelkasten: Topic Maps, Back to the Future ~ The Zettelkasten (&quot;card case&quot;), introduced by the German social scientist Niklas Luhmann in 1981, is an external memory system composed of notes linked through explicit cross-references. A mesh of cross-references allows larger conceptual structures to emerge as the collection grows. Luhmann&apos;s Zettelkasten was entirely paper-based. Few efforts to computerize the model seem to have achieved or even understood the levels of engagement and serendipity that Luhmann claimed. I present a framework for understanding how such a system can achieve Luhmann-level support and speculate about why and how so many implementations have fallen short. I synthesize aspects of information theory, cognitive science, human interface, movie production practice, data modeling, and library science to illuminate key concepts underlying highly effective thinking support. Remember Topic Maps and back-of-the-book indexes?</OtherInformation>
      </Objective>
      <Objective>
        <Name>BoF Session(s)</Name>
        <Description>Choose topics to discuss and keep the conversation(s) on topic</Description>
        <Identifier>0d853359-1f66-4fdf-9e4e-8a187f9f1fba</Identifier>
        <SequenceIndicator>8-6-17:15</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Generic_Group">
          <Name>TBA</Name>
          <Description>Discussion Leader(s) to be Announced</Description>
        </Stakeholder>
        <OtherInformation>Thursday 17:15… | Birds of a Feather Discussion(s) ~ BoFs are meetings, or mini-meetings, devoted to a topic of interest. See the BOF page to request a BoF and the conference portal for the BoF schedule.</OtherInformation>
      </Objective>
    </Goal>
    <Goal>
      <Name>Day 5 - Friday</Name>
      <Identifier>4c23fb30-a049-4f9c-b73f-8aa322052afb</Identifier>
      <OtherInformation>Friday, August 7, 2026</OtherInformation>
      <Objective>
        <Name>BoF Session(s)</Name>
        <Description>Choose topics to discuss and keep the conversation(s) on topic</Description>
        <Identifier>99ae234b-704f-473a-8692-96d85d53a8b7</Identifier>
        <SequenceIndicator>8-7-08:00</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Generic_Group">
          <Name>TBA</Name>
          <Description>Discussion Leader(s) to be Announced</Description>
        </Stakeholder>
        <OtherInformation>Friday 8:00 - 9:00 EDT | Birds of a Feather Discussion(s) ~ BoFs are meetings, or mini-meetings, devoted to a topic of interest. See the BOF page to request a BoF and the conference portal for the BoF schedule.</OtherInformation>
      </Objective>
      <Objective>
        <Name>TEI Rendering with Vue.js</Name>
        <Description>Leverage XSLT, SaxonJS, and the Vue.js front-end framework to publish a readable, maintainable, and lightly-hosted TEI-encoded Arabic scholarly edition</Description>
        <Identifier>44524d97-134e-4600-b214-251ab39fea4d</Identifier>
        <SequenceIndicator>8-7-09:00</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Takatomo Inoue</Name>
          <Description>Waseda University</Description>
        </Stakeholder>
        <OtherInformation>Friday 9:00 - 9:30 EDT (+ Q&amp;A 9:30 - 9:45) | Efficient Development of TEI Rendering Web Applications Using Vue.js (LB (late-breaking)) ~ Critical editions of manuscript sources are important tools for researchers, but paper-based editions cannot be updated. This case study introduces a TEI-encoded Arabic scholarly edition, which was created as part of the author&apos;s dissertation. What did it take to create an interface that is readable, easy to maintain, and light on hosting requirements? This presentation will describe how XSLT, SaxonJS, and the Vue.js front-end framework can be leveraged to publish TEI digital editions.</OtherInformation>
      </Objective>
      <Objective>
        <Name>Music Notation Markup</Name>
        <Description>Survey music notation markup languages — SMDL, MusicXML, MEI, ABC, ChordPro — and assess whether any meet the practical needs of musicians seeking to create practice tracks from electronic score sources</Description>
        <Identifier>80ae67e0-0443-4437-bec1-2cc883598758</Identifier>
        <SequenceIndicator>8-7-09:45</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Joshua Lubell</Name>
        </Stakeholder>
        <OtherInformation>Friday 9:45 - 10:15 EDT (+ Q&amp;A 10:15 - 10:30) | Music Notation Markup Languages with a MusicXML Case Study ~ How can a retired markup geek who sings bass in a choir create practice tracks from electronic sources? Music notation software enables musicians and scholars to edit and analyze musical scores, convert them into audio formats, and share them in searchable databases. Music notation markup languages attempt to encode the multitudinous information present in a piece of sheet music. Efforts to standardize music in descriptive markup started with the SGML-based SMDL (Standard Music Description Language), which was incorporated in HyTime (Hypermedia Time-based Document Structuring Language). Modern XML offerings include MusicXML and MEI (Music Encoding Initiative). ABC and ChordPro are popular text-based music annotation approaches. Do any of these meet my need? Let&apos;s find out!</OtherInformation>
      </Objective>
      <Objective>
        <Name>Centralised Markup Events Index</Name>
        <Description>Create a centralised index of markup conference proceedings — covering scope, processes, challenges, and solutions — to enable researchers to find prior work and build on it</Description>
        <Identifier>3de7677a-8b63-4b54-b7e0-be1b50b270d3</Identifier>
        <SequenceIndicator>8-7-10:45</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Sheila E. Thomson</Name>
        </Stakeholder>
        <OtherInformation>Friday 10:45 - 11:15 EDT (+ Q&amp;A 11:15 - 11:30) | A Centralised Index of the Sisterhood of Markup Events ~ When I have an idea for a paper, I like to check if someone&apos;s already presented it or something similar. If it&apos;s not a new topic, then maybe I can build on what&apos;s gone before - but I need to know what that was. There are also occasions when the research is not driven by a prospective project but simply curiosity or to support learning. Each time I go through this process, I think to myself &quot;Wouldn&apos;t it be nice if there was a centralised index of all the markup papers?&quot; This paper is a case study on the creation of such an index, in particular its scope, processes, challenges, and solutions.</OtherInformation>
      </Objective>
      <Objective>
        <Name>AI and Open Source</Name>
        <Description>Identify social, economic, environmental, political, legal, and technical concerns raised by AI/LLM-generated code in XML infrastructure projects, and offer an AI Policy Score Card to guide Open Source projects&apos; engagement with AI</Description>
        <Identifier>cb8bc005-2ecf-4695-98c0-4d9df2e75b5c</Identifier>
        <SequenceIndicator>8-7-11:30</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Adam Retter</Name>
          <Description>Evolved Binary</Description>
        </Stakeholder>
        <OtherInformation>Friday 11:30 - 12:00 EDT (+ Q&amp;A 12:00 - 12:15) | What does AI mean for Open Source? ~ Quite a few XML infrastructure projects are now accepting AI/LLM generated code. Some of these projects are quite impressive and some I characterize as &quot;slop&quot;. The sudden meteoric rise of Large Language Models (LLM) and associated tools has caught many software developers unawares, leaving them suddenly ignorant, and arguably under-skilled. LLMs, whilst still advancing, have recently demonstrated impressive capabilities in their ability to assist software developers in their day-to-day tasks (e.g. coding new features, and locating and fixing issues). However, the use and adoption of LLMs presents many challenges for society as a whole; many of which are not in themselves technical concerns. In this examination of the current and perceived impact of this technology upon Open Source we identify several social, economic, environmental, political, legal, and technical concerns regarding the use of LLMs in Open Source projects. We contribute guidance around defining an AI Policy for Open Source projects and offer an AI Policy Score Card to assist projects in defining and declaring how they wish to work with AI or not.</OtherInformation>
      </Objective>
      <Objective>
        <Name>Open Mike</Name>
        <Identifier>191c912d-124b-4e82-b174-97cbfbf4a083</Identifier>
        <SequenceIndicator>8-7-13:30</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Generic_Group">
          <Name>Conference Participants</Name>
        </Stakeholder>
        <OtherInformation>Friday 13:30 - 14:00 EDT | Open Mike: Anything Goes ~ Balisage short subject open microphone. All conference participants are invited to give a 2 to 10 minute presentation on ANY topic (within the limits of the conference Code of Conduct). Use video, sound, bullet point slides, cartoons, visualizations, SW demonstrations, or just yourself as a talking head. Anything goes!</OtherInformation>
      </Objective>
      <Objective>
        <Name>Federal Register XML Modernization</Name>
        <Description>Convert Microsoft Word files containing legacy SGML tags into USLM XML format through a multi-step incremental process managing hierarchy construction, formatting normalization, and table conversion at GPO</Description>
        <Identifier>e4dce055-4f14-4368-bf3a-e7725ee755e9</Identifier>
        <SequenceIndicator>8-7-14:00</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Betty Harvey</Name>
          <Description>Electronic Commerce Connection, Inc.</Description>
        </Stakeholder>
        <OtherInformation>Friday 14:00 - 14:30 EDT (+ Q&amp;A 14:30 - 14:45) | Making Hierarchy out of Nothing at All: Federal Register Data Modernization ~ The raw material for the Federal Register, published daily, comes to GPO from agencies as Microsoft Word files that often include legacy SGML tags as text. The challenge is turning this stream of paragraphs into a deep tree. Getting these into the United States Legislative Markup (USLM) XML format that GPO uses is a complex process, broken into many small incremental steps that are managed individually. Because Word inserts many redundant codes, a large part of the conversion process is filtering these out and merging similar formatting before developing the first levels of hierarchy. Recognizing section headings often depends on multiple rules for recognizing patterns of both formatting and text (such as numbering styles) in the content. Word tables are converted to HTML tables; these are currently converted to an old GPO table model but in the future will be CALS tables. Because Word styles are inconsistently used, interpretation is necessary. In the future, perhaps we will be able to capture Word styles in the initial conversion to XML. Many tagging decisions now depend on subject-matter experts. The service is a work in progress.</OtherInformation>
      </Objective>
      <Objective>
        <Name>Nice Things (Reflection)</Name>
        <Description>Reflect on technologies — HTML, XML, SVG, MathML, XSL-FO — that have been broken, abandoned, or undervalued, and examine what technologies will sustain lasting value for society</Description>
        <Identifier>37ac00db-fba5-461e-81d2-c1894d209c4c</Identifier>
        <SequenceIndicator>8-7-14:45</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Alex Miłowski</Name>
        </Stakeholder>
        <OtherInformation>Friday 14:45 - 15:15 EDT (+ Q&amp;A 15:15 - 15:30) | We Just Can&apos;t Have Nice Things (Reflection) ~ When given a new toy, we may play with it too hard or in a way not intended, and it just breaks, and is irreplaceable. But sometimes, breaking things leads to insights and innovations. We&apos;re tempted to get rid of the things that break often because they are &quot;bad&quot; or &quot;poorly designed.&quot; Often, they&apos;re just nice things we&apos;ve failed to curate into better things. We have had so many nice new things . . . HTML, XML, SVG, MathML, XSL-FO . . . that have been broken somewhere, some time. What technologies will sustain value for society? We just can&apos;t just have nice things — we have to make them.</OtherInformation>
      </Objective>
      <Objective>
        <Name>Closing Administrivia</Name>
        <Description>Mulberry Technologies</Description>
        <Identifier>bbb583f7-f7de-4a88-bc97-29dc01392edb</Identifier>
        <SequenceIndicator>8-7-15:45</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Person">
          <Name>Debbie Lapeyre</Name>
          <Description>Mulberry Technologies</Description>
        </Stakeholder>
        <OtherInformation>Friday 15:45 - 16:00 EDT | Closing Administrivia ~ Announcements, thanks, and other administrative tasks are the necessary plumbing associated with events such as Balisage. In this session we will try to keep the administrivia as short as possible while also asking, telling, thanking, and recognizing as appropriate.</OtherInformation>
      </Objective>
      <Objective>
        <Name>Invitations to Future Markup Events</Name>
        <Description>Describe the focus, expected attendees, and unique characteristics of a variety of markup-related conferences and events scheduled throughout the year and across the planet</Description>
        <Identifier>89ba5de5-a8cf-4cdb-9830-09af0a8b1acc</Identifier>
        <SequenceIndicator>8-7-16:00</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Generic_Group">
          <Name>Representatives of Markup-Related Events</Name>
        </Stakeholder>
        <OtherInformation>Friday 16:00 - 16:30 EDT | Conference Closing: Invitations to Future Markup-Related Events ~ There are several markup-related conferences and similar events scheduled throughout the year and across the planet. Representatives of those events have been invited to describe the focus, expected attendees, and unique characteristics of those events.</OtherInformation>
      </Objective>
      <Objective>
        <Name>It&apos;s Been Fun!</Name>
        <Description>Share favorite memories of Balisage through the years — presentations, Balisage Bard entries, colleagues met, venues remembered — as the final conference closes after 30 years</Description>
        <Identifier>d10f4305-061f-498b-82b8-0d0e8ad179b8</Identifier>
        <SequenceIndicator>8-7-16:30</SequenceIndicator>
        <Stakeholder StakeholderTypeType="Generic_Group">
          <Name>Conference Participants</Name>
        </Stakeholder>
        <OtherInformation>Friday 16:30… | It&apos;s Been Fun! post-conference reminiscing ~ Balisage is over, not just for this year but forever. This is the time to share favorite memories of Balisage through the years. Was there a presentation you keep thinking about? Did a &quot;Balisage Bard&quot; entry make you laugh so hard you remember it? Did you meet a friend, a mentor, or a colleague at Balisage? Was there something memorable about one of the Balisage venues? Come reminisce on what has, on the whole, been a good run.</OtherInformation>
      </Objective>
    </Goal>
  </StrategicPlanCore>
  <AdministrativeInformation>
    <StartDate>2026-08-03</StartDate>
    <EndDate>2026-08-07</EndDate>
    <PublicationDate>2026-07-21</PublicationDate>
    <Source>https://www.balisage.net/2026/Program.html</Source>
    <Submitter>
      <GivenName>Owen</GivenName>
      <Surname>Ambur</Surname>
      <EmailAddress>Owen.Ambur@verizon.net</EmailAddress>
    </Submitter>
  </AdministrativeInformation>
</StrategicPlan>