This is the text transcript for Semantics and the Web: An Awkward History, available at https://www.youtube.com/watch?v=77qDvd5uOx8 . An HTML version is available at http://simonstl.com/balisage/transcript09042021.html, and the original paper for the Balisage conference, with more detail about 'semantic' is at https://www.balisage.net/Proceedings/vol26/html/StLaurent01/BalisageVol26-StLaurent01.html . Hello! This is a story where we, the fans of meaning conveyed by markup, mostly lose after a long winning streak. To soften the edges a bit, I'm telling the story with Playmobil figures. This is... a lot of sugar wrapped around a fundamentally bitter flavor. Hopefully the result pulls off that trick like chocolate does. Balancing ingredients is hard, though, and I'm not sure the bitterness has had enough time to ferment. I hope this new telling of old stories will help you re-examine what you know, to revisit community and communities. Playmobil, though amazing, has obvious limitations, so all characters and situations are extremely approximate. Many thanks to Kyle Weems (also known as CSSquirrel) for permission to use his comic. As always, my opinions are likely not my employer's opinions. "Markup" lets us add labels to content, typically text content, to create labeled structures. It is a relatively lightweight way to create information that we can share across multiple platforms, reuse in different contexts, explore in a text editor, and transform into something different. Compared to many other formats, markup is easy to process and manipulate with generic tools. It has just enough flexibility for many, though not all, use cases. Sometimes it's a good idea to go back to the origins, to figure out how we got here. [Music] No. That's not how it was. Moon-watcher and his friends are thrilling, but as someone reminded me when I first presented this bit, there was meaning before markup. In the Beginning was the Word, not the Tag. Or did whitespace come first? Most tellings of markup language history and theology start with Charles Goldfarb. Like all the primary characters you'll see in this talk, he's a point at which ideas converged. "Generic coding", later known as markup, first emerged in the late 1960s, when William Tunnicliffe, Stanley Rice, and Norman Scharpf got the ideas going at the Graphics Communication Association, the GCA. Goldfarb's implementations at IBM, with his colleagues Edward Mosher and Raymond Lorie, the G, M, and L, made him the point person for these conversations. Markup didn't have angle brackets yet, and it looked... different, but it is markup, with start and end tags. Putting labels into text, and then having separate programs process that text and labels, opened up new possibilities. Clearly, these were good ideas, and IBM had the equipment and people to run with them. More and more people heard about what was possible here, and interest spread. And spread, and spread. Tools for applying GML mostly came from IBM. GML work focused on publishing, especially within IBM, itself a vast publisher. They were also happy to sell you printers, compositors, and a variety of tools for creating and managing documents with GML. There was something great starting here... First the GCA, then the American National Standards Institute (ANSI), and then the International Organization for Standardization (ISO) brought together experts and implementers to build a more comprehensive set of tools. The military-industrial complex eagerly participated. There is a securely invisible figure there. Many professions saw opportunities and possibilities in this work. People who wanted to build things and clean things up were eager to join. The crowd grew bigger as SGML emerged, with supporting technologies like HyTime for hypertext, Document Style Semantics and Specification Language, abbreviated DSSSL, and more appearing. This looks more familiar. In those days when storage was precious, markup minimization was attractive. You can identify the structure, the elements, of this document using the start tags. Who needs end tags when your software can figure out logical boundaries? Skipping end tags is the smallest and simplest form of minimization, and there are many more options. SGML offered lots of tricks to keep things small, offering convenience to both human authors and storage capacities. The price of that was software complexity, and to some extent Document Type Definition, or DTD, complexity. The SGML tools landscape was a superset of the GML landscape, with tools available from multiple vendors for a variety of different kinds of projects. You were hiring people, often consultants, as much as you were choosing software. Much of the software was expensive, but even the open source tools like sgmls, sp, and Jade presented challenges. You might grab an SGML parser that could process your style of markup, but then what? Even the tools for sale were generally software projects more than software tools. You could find a set of tools that fit your project, and assemble and customize them to meet your needs. Companies customized SGML editors to their own vocabularies and workflows. The details of HyTime's hypertext connections depended on what and how you wanted to connect. DSSSL projects needed developers to create stylesheets that produced results. You could always store documents in a file system, but if you wanted useful querying, fragment management, or versioning, you probably needed to build and integrate something bigger. Some SGML tools were more complete than others, but even in the best situations, integration and maintenance were a lot of work. One of my favorites was the TEI pizza chef, an interface for mixing and matching markup options. "What do you want in your documents?" is kind of like "what do you want on your pizza?" They've renamed it Roma, but the concept is similar. SGML included a sample vocabulary, built on a model from the earliest days of GML. The American Association of Publishers and others used it regularly. At CERN in 1989, Tim Berners-Lee extended that vocabulary slightly for the Internet, to help researchers communicate. His server, sharing real information, along with a simple browser, may have been more convincing than the diagram. This comes a bit later, from 1999, but does a nice job of showing HTML in use. It has tags like SGML, and uses attributes mostly for links. This document included tags at the end of elements. The first few people liked it And they brought more friends, including people who started writing more browsers, with new capabilities that Brought in more people as the Web become more accessible. The crowd kept growing, reaching a larger and larger slice of not always technically-sophisticated people. So many people, so quickly... and the diversity of applications was overwhelming. Even Santa Claus showed up. Many respectable people started using the web for business. Kids, ponies, trash pandas, and more came on to the Web quickly. There were apparently a few pirates, too. The web could go as far as your imagination would take you, Presenting information in many ways to many people. As the saying goes, "On the Internet, no one knows you're a dog." And, of course, everyone knows that the Web is primarily a medium for spreading cat pictures. Pretty much from the beginning, of course, there were bots of various kinds. Proxies and spiders came first, but bots crawl HTML constantly. And, of course, there were people wearing tinfoil hats. People wanted to learn about the Web, especially to share content on the Web. HTML was the foundation, decorated by CSS and JavaScript. The HTML tooling opportunities were vast, and came in many forms. The most visible part of the Web story was the browser. When the Web first appeared, so did a burst of browsers across all kinds of platforms. Lots of them were licensees of the same Spyglass Mosaic code, but many of them were original creations or added their own perspectives. It wasn't all about coding, though. Much like we continue to talk about people "surfing the Web", I had lots of conversations with people early in the Web who described creating content in different ways. Obviously, creating web sites was like publishing, learning from print, though clearly electronic. Some of those workflows, tools, and ideas transferred well. Or music. Many voices coming together, integrating, with flow among different themes. Web development was like cooking or baking, mixing ingredients, cooking them just right, and plating them for the world to enjoy. The Web was a new medium joining other 20th century media, especially but not only electronic media. Many described their efforts in terms of fiber arts, gathering the threads of hypertext, spinning stories, weaving the web, stitching it all together, to see how it fit and how it wore over time. Even though the web safe palette was only 216 colors, I heard a lot about painting - indeed, color and design more broadly became more and more important as the technology evolved. There were so many styles of tools Ready for use in small workshops Or gardens for code. Some of this work was demolition. Of course, construction was a key metaphor - "Under construction" became so common a phrase that it fell out of style from overuse. And some of the construction was at a truly massive scale, bigger than anything that computing had exposed directly to the public. Because HTML was structured text, and computers had more and more audio capabilities, the Web was more than just a visual medium. Screenreaders had existed for a while, but the Web opened new possibilities, thanks to a structured foundation of markup and browser APIs. Bringing content to far more people. Because every HTML document was a text document, different approaches could create and edit it. Handwork with text editors was often how people learned, but it's also how people, even now, maintain pretty complicated sets of documents. Text-based HTML editors with features like highlighting syntax, collapsing sections, and convenient search tools made it easier to work with markup. As projects got more complicated, turning into groups of documents with repetitive navigation, content, and style, template systems could ease the work. Over time, What-You-See-Is-What-You-Get, or WYSIWYG content editors appeared - though some of them were powerful yet clunky. The resulting markup was not always precise. A whole range of options quickly grew. On the server side, the Common Gateway Interface, CGI, and its successors let developers build large projects. Solid foundations for different kinds of projects might use the same core materials, but also different tools at different scales. Dumpsters are available in a variety of sizes and styles. To be honest, though, these have always been available. Demolition of old projects, waste, and disasters are common and frequent parts of computing. Some dumpsters are more exciting than others. The Web was so popular that there were even browser wars. Being a browser vendor was hard. Over 100 companies licensed the Spyglass Mosaic code and in the end only one kept going - Microsoft. Internet Explorer had massive backing from a company with other strong supporting projects. Netscape and Microsoft were, pretty quickly, the "big two" of the browser world, fighting over the treasure of the Web. Both companies had browser teams focused on winning this space, Evaluating changing landscapes for opportunities. While a lot of the battles were over strange issues, Not everything was a fight - in an HTML 3.2 meeting, Netscape supposedly dropped BLINK and Microsoft matched it by surrendering MARQUEE, but most things were harder than that. Some were huge, determining the future of the Web for decades to come. It was clear that doing all formatting directly in HTML was a maintenance nightmare, but what should the formatting layer look like? The W3C's Cascading Style Sheets defined a way to declare that "this kind of element, identified by this selector, should have these properties applied". You didn't need to be a programmer to use it. Microsoft backed CSS. Would the presentation layer for the Web be the W3C's declarative Cascading Style Sheets, or more traditional imperative programming code? Netscape preferred JavaScript-Based Style Sheets. These applied the programming language that Netscape had created to the challenges of formatting. Instead of a list of declarations, JSSS ran a JavaScript program. That imperative code set formatting properties, using any JavaScript logic you wanted. The battle was joined. It wasn't just Netscape vs. Microsoft - a lot of developers using their tools also took sides, shaping their projects to fit one model or the other. Money and the shape of the Web Were enough to bring a lot of people into the battle Following leaders with corporate and technical agendas.... Cascading Style Sheets won that battle, but every battle had its costs. Most people would recover, though many people left the Web or careers based on the Web out of frustration. Next up was the crucial question of how code would interact with the contents of HTML documents. Could you script all parts of a document, through a document object model, or would only certain pieces, LAYER elements, be available to script? Microsoft had built the document object model into the "dynamic HTML" of its Internet Explorer 4.0. A lot of developers, myself included, were eager to join the "dynamic HTML" charge. Netscape required additional LAYER elements, and you could only script those layers. Developers quickly found that supporting both in a document was difficult LAYERs were limiting, and the additional markup didn't always work well with document editing and management tools. The Internet Explorer side advanced. A tight formation of DOM nodes was hard to defeat. LAYERs cost Netscape a lot, and never made it to standardization. Instead, Netscape joined the Document Object Model work at the W3C. From the perspective of "let's create meaningful markup with minimal clutter," this result was a very good thing. Again, though, many of the casualties were developers. The perpetual battle wasn't about a specific technology. From the beginning of the Web, developers had found and relied on bugs in browsers. Developers whose sites depended on the bugs wanted them to continue as they were. Many were parsing bugs, some were layout bugs... so many possibilities. Netscape supported one set. Microsoft had done the same thing, but of course the details were different. As always, mostly web developers suffered, wondering why things that worked in one browser didn't work in another. In the midst of these headaches, a group of developers decided it was time to do something different not pick sides among the contestants, but intervene from the middle. The group tried to break up the battles Trumpeting the message that web standards would make developers' lives easier, to both Microsoft, and Netscape, and others. Fighting over features mostly moved from browser releases to committee rooms. They also worked on getting developers to move away from table-based layout and spacer GIFs, which were hard to maintain, to cleaner HTML structures with CSS. Despite its explosive growth and popularization of markup technology, the Web's use of markup did not go over well in all quarters. "The Web sucks. It is lightweight, shallow, trivial, and disposable. It is simple enough that any idiot can use it, and this, weirdly enough, is considered good." That was Tim Bray, in 1995, in Wired magazine. The SGML community knew it could do more. Team XML was forming. It wasn't just two leaders - Jon Bosak and Tim Bray built on SGML ideas and a growing eagerness in the community to try something simpler. Growing interest in Web Standards created an opening for a new approach to neatly structured markup. Jon and Tim spearheaded a new process, at the home of the Web, the World Wide Web Consortium, the W3C. In a dark corner at the W3C, though certainly not secretly, the SGML Editorial Review Board, eventually the XML Working Group, put SGML on a diet. Starting with SGML itself - though DSSSL and HyTime would come soon - they shrank the specification dramatically, with help from Technical Lead James Clark. Perhaps they didn't literally take chainsaws to the specification Or reduce it to a postcard, but they dropped a lot of features to produce something simple to standardize and implement across a wide variety of software platforms. XML's discipline made markup syntax much easier to process. XML lacked minimization rules, but it offered structural flexibility similar to SGML's. Committees could describe markup vocabularies and structures. Or, because it was easy to process - a browser was enough to get you started - you could create your own personal markup formats. Of course, not everyone stayed around for XML Some people remained with strictly SGML work, preferring to keep key features, but facing a slow fade as tools development shifted primarily to XML. The XML crowd grew, though not to the same size or diversity of uses as the HTML crowd. XHTML, which put HTML into XML syntax, helped spread XML to a wider crowd. The Steering Committee of the Web Standards Project said "XML's strict rules for conformance give XHTML a backbone that HTML has never had, and promise to open up new possibilities for XHTML processing, storage, and creation as the standard spreads. It's a big step forward." Well, okay. Really, that was me quoted, though, with their imprimatur in a press release. Tim Bray was on the Steering Committee too, so I think his opinion of the Web might have shifted by then. Lots of people did come to XML itself, because it offers a standard and relatively simple way to create labeled information and documents. It wasn't the first to propose that, but it was the first to demonstrate that it could be useful, powerful, and flexible, all at the same time. And, of course, there were bots, again. XML made some of their jobs easier, though in practice many kept their parsing powers much more flexible than XML required. Sometimes bot-like creations even appeared "in person" at XML conference hotels. The SGML crowd had a bigger vision for XML and the Web. XSLT - descended from DSSSL - promised to replace the browser's rendering with CSS. XLink, descended from HyTime, described much more sophisticated linking. Only a few parts of that vision happened in web browsers, though. By 2000, the three most active browser vendors supported XML document display using CSS, but in different ways. Opera's browser let you create hyperlinks with CSS extensions. If you wanted to try the lightest part of the emerging XLink standard, a much simpler descendant of HyTime, Netscape could help. XSLT was a coming attraction. Microsoft's offerings were a little different. Internet Explorer 5 shipped with an early XSL engine, but promised to catch up to "official" XSLT soon. They also included XML data islands and, though its importance wasn't clear yet, an early version of XmlHttpRequest logic. People wanted, though, to work with XML outside of the browser. While HTML focused on making things happen in the browser, XML offered a vast array of tools beyond that - if you were willing to program the connections yourself. XML's release set off a huge wave of new tools, both large and small. XML parsers didn't need to be part of a browser. They even came in multiple flavors, event-based SAX parsers and tree-based DOM parsers. XSLT processors let you transform XML to other XML or HTML or something else, whatever you wanted. XML databases let you store and manage XML documents, wherever you wanted. Consultants could use even more precise tools to build exactly the systems you needed. Though if you looked around, both information and tools were available to do it yourself. A whole set of websites appeared. A print XML magazine was even available at newsstands for a while. It was an XML gold rush! Prospectors brought knowledge and tools to the mine, welcomed by media support for the latest and greatest. Weird scenes inside the gold mine ensued, as companies and developers applied XML to everything they could. Business-to-business interactions, common office applications, object serialization and storage, configuration files, content for the web, print, ebooks, and elsewhere... it was a busy busy time. XML and its surrounding technologies could be lucrative. Many companies and consultants hauled gold out of these mines, earned from complex projects. After a long day in the mines, community could help. There were often laptops and phones as well as mugs out, and bots learning from electronic conversations. XML quickly moved to the core of web services and messaging. Some built directly on structures within XML documents, like SOAP, while others took a more general approach, working with supporting protocols, like REST. Using HTTP's key verbs of GET, PUT, POST, and DELETE, developers could build complex "RESTful" applications. For senders, REST combined an HTTP verb, a URL hosting a web server, and a message. XML made a great payload for messages sent via REST, providing easily accessible internal structure. People sent piles of XML from place to place. Web Services of many kinds were the new big thing. It was a heady time, with lots of excitement and dreams of more to come. Of course, that enthusiasm changed things. That tiny spec Quickly turned into a book (for me, literally a notebook) of specifications And then a library of specifications And more specifications And yet more specifications... Some of the standards sprawl was specifically about the markup, but some of it was about building the Semantic Web or Web Services on top of that core. The layering wasn't always neat, especially for namespaces and schemas. XML's ambitions kept growing. Demolishing old projects to make way for the new XML was a common activity. Discussions that started with parsers and processors shifted to larger frameworks and prefab communications. Markup construction sites were busy, though one group of past supporters abandoned the specifications as they grew: the browser vendors. They didn't need these parts and their customers weren't asking for them. XML had appeared while browser vendors were still competing. As Internet Explorer dominated, Microsoft declared victory. Releases became less frequent with fewer features. A decade later, when Chrome took over Internet Explorer's dominant position, it initially sold itself on performance and stability, not new possibilities for markup. A lot of XML work was really object serialization, as a close look at, say, Apple plist files, or any of the Microsoft Office formats that use XML, or the "XML on the wire" web services approaches will reveal. A text-based technology that was meant to be an object serialization format could have huge advantages. Douglas Crockford extracted a convenient "does enough" object notation format that was already part of JavaScript. The full JSON standard is 16 pages. Crockford presented JSON at XML 2007, and John Cowan replied from the audience that "I, for one, welcome our new JSON overlords." Text, arrays, numbers, and strings are often all it takes to store and convey information. The crowd that had been using XML for APIs and object serialization stayed to hear and implement Crockford's message. JSON syntax was also easy to turn into a neat subset of YAML (YAML Ain't Markup Language), which had spun off of the xml-dev mailing list earlier. JSON promised simpler thinking. "All you need is this little bit, and you can get back to working with objects instead of documents." There wasn't much to sell, exactly - JSON consulting is far more occasionally a thing than XML consulting was - but people lined up to get the simple connection to their tools. The same RESTful approach to building remote services, for example, worked just fine with JSON. All that really changed was the format of the messages themselves. So many new messages, so few angle brackets. Now, the wrecking ball came for XML integration. Not for all of it, of course, but the main structure got a major trim. At the same time, XHTML faltered. Many web developers were unenthusiastic about precision markup syntax, and a key crowd of programmers inside the browser makers wanted script everywhere possible. JavaScript found its moment. The W3C was deep into declarative and often XML models, but some powerful W3C members were not. Flash, Ajax, and then iPhone and Android apps drove endless conversations about applications. And who builds applications like those? Programmers. Typically, programmers used to imperative programming and scripting. Google accommodated those developers by pouring resources into its V8 engine, making sure that JavaScript could run fast. After the W3C rejected their position paper. that crew from Opera and Netscape set up their own conversation at WHATWG, and others were clearly interested. Google and Apple joined quickly, with Google's Ian Hickson, Hixie, the most visible. What started as a proposal to add functionality to forms quickly turned into a full proposal for a next version of HTML, HTML5. As more and more people came over to the HTML5 side The W3C at first tried to include their ideas - after all, the WHATWG core was W3C members - but eventually it surrendered. In 2010, the W3C halted work on XHTML. Official XForms work ended in 2015. In 2019, the W3C stopped work on HTML, leaving it to the WHATWG ‘living standard'. The WHATWG core is small, but control of the gateway specification for the Web - and its implementation! - gives them huge power. This wasn't, of course, a simple or friendly conversation. "Objective" is always a huge red flag for me, but I'll leave it to you to evaluate this statement. I can't tell the story as well as Kyle Weems already has, in his CSSquirrel comics. Many parts of CSSquirrel only make sense if you know HTML and CSS culture deeply, but I think this moment of "Irrelevant. We'll tell you how HTML5 is going to be, and you'll like it" is clear enough on its own. So far, WHATWG has triumphed. If you're talking about contemporary HTML, their work is now primary. Even beyond the specifications, though, more and more HTML documents are collections of div elements. HTML hasn't gone away - it's still in there - but it gets less and less attention. Teaching and tooling changed. JavaScript replaced HTML as the primary focus of web development, while libraries and frameworks became a more common part of the conversation. Even standard simple uses of HTML switched to Markdown, ASCIIdoc, and similar. At least they generate markup that's more meaningful than layers of DIVs? XML's growth curve had already flattened. Developers had carved out the subsets they preferred to use. Now XML started shrinking fast as JSON took over API duties, as HTML5 took over, and as developers shifted toward models and frameworks where all DIVs are created equal. Markup, and especially the semantics it could represent, mattered less and less. The largest and most lucrative gold mines shifted, to become all about JSON and apps. Web developers moved further toward DIVs as the primary structural element. Development resources shifted away from XML and markup. Even when it is still supported, XML is often deprecated. Markup was out of style. XML was old-fashioned. Semantic markup, presentational or not, fell out of HTML use. Worse, HTML was (and is) routinely derided as unimportant because it was "not a programming language". The WHATWG crew came to Balisage to tell the crowd that the web ecosystem routed around the damage of XML's influence by making HTML better suited for extensibility than ever before". Which, well, web components aren't really taking the world by storm so much either. At its former stronghold, the W3C, the XML Core Working Group ended in 2016, and the XSLT/XQuery Working Group ended in 2018. The Web toolyard changed dramatically. HTML went from the center of everything to a tiny corner where beginners could get their feet wet. Fewer and fewer HTML elements are used more and more, with generic DIV and SPAN often used even in cases where HTML offers something more specific, more accessible. Newcomers fill their pitchers with these bland formulations and hammer labels onto them for styles and JavaScript to use. Designers still focus on creating visually appealing experiences, creating work that adapts to both larger and smaller canvases. Design is at least recognized as an important field of work, but frameworks, build tools, and programming culture constantly demand that styles be treated like, even as a part of, JavaScript. But Psst... kid... over here. There's still some of the old power left, built right into your browsers. You don't have to be old to use semantic markup, or to focus on accessibility. All of this can be yours, and it's easier to read anyway. Sometimes you can even build a conversation, or a class, around the possibilities. It's a small crowd, though. The valued parts of client-side web development in the browser, the parts that companies want to pay for, became front-end engineering. Construction and build metaphors are now about JavaScript. Other approaches still exist, but programmers doing engineering are the respectable part of Web development now. Programming languages, not markup languages. There is still markup, though in many cases only the logic driven by JavaScript provides it meaning. Way over on the other side of the tool yard, XML tools persevered. Only the 1.0 versions of XML and XSLT made it into browsers, but because XML hadn't bonded itself tightly to web browsers, you could still get XML parts if you wanted. They might not always be maintained, of course. In some cases, JavaScript provided glue. Tools like SAXON-JS provide XSLT 3.0 support in the browser, at just the cost of a 500KB download. It does, of course, also work on JSON. We who value markup, who come to conferences like this, are now, effectively, a remnant church, the ones who remain. I know that many people, for many good reasons, aren't eager to be compared to Christian churches, especially churches that see themselves holding on as the last beacons in a sinful world. Christians may wonder why I'm comparing markup to churches. I apologize for that awkwardness and Christian-centricity, but the metaphor works too well. Like many remnants, there's a strong dose of looking to inner strongholds for answers, a denial that we have lost anything, and contempt for the worldly. Some of the review comments for the paper behind this presentation felt very much in that zone. "The majority of human authored content on a daily basis is produced in XML, via MSWord, ODF-based products, which is to say nothing of the US Government Printing Office output. A large amount of web traffic does consist of JSON and other semantically bare formats, but does anyone care about the semantics of porn downloads?" Hmm... And then a question? "And what about all the other folks making submissions about how, nevertheless, they persisted -- using semantic markup? Are they just technical chickens running around not realizing their heads are cut off?" I'll try to focus on the bright side. A different reviewer suggested, "Rather than a eulogy for markup's heyday, how about a look at how views of, and use of, markup have changed over time and speculate on how they might change into the future?" I don't exactly have that, but - There is a sanctuary. Or sanctuaries, actually. I'll focus on this one, the Balisage conference, today, but also remember XML Prague, XML Summer School, Declarative Amsterdam, Markup UK, some web conferences, and more. Come on in, explore the stained glass for a moment, and let your eyes adjust to the light. [silence] Dearly beloved, we are gathered here today to discuss the many things you can achieve with well-considered markup vocabularies and workflows. We have a long and welcoming history despite regular change. The crowd is somewhat grayer, but still has some amazing hats, a library of specifications outlining possibilities, and eagerness to talk about documents, data, standards, implementations, and more. The audience is, as always, a mix of old-timers, newcomers, and some bots. We've gathered for decades to share information with each other, to discuss sacred texts, even - maybe especially - forgotten texts. Sometimes, we convene a panel of people with very different ideas who all want to share and compare. It's not just talk, of course. The markup flame stays lit. You can explore What are effectively church gardens, delightful testbeds, places to try things out before scaling them up. A careful selection of tools and materials, and detailed descriptions of how to use them, makes it easier to get things right. Weeding and watering keep things growing. We keep things looking tidy. The flowers of past work remain beautiful. Even inside the church, there is the occasional strawman. Don't you have some too? Our meeting room celebrates technologies and people who have come before. Maybe we can find solidarity across approaches? The walls tell stories, of technologies and people triumphant and not triumphant - we learned from them all. Banners and posters celebrate organizations, specifications, and community gathering places. It's not all just formal services - we gather for coffee, cake, and other enjoyable treats supporting conversation. We're happy to talk about clean structures, minimally redundant markup, humans in the loop, conversions, overlap, creating more XSLT hackers, digital humanities, trees, graphs, ebooks, cookbooks, stylesheets, projects gone wrong - or right - and so much more. Even in this much smaller remnant there are still fields of interest that only connect through markup, not even always markup with angle brackets. Everyone is welcome - even, hopefully, some programmers Who might, perhaps, be looking for a change.