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

There is a basic culture surrounding the “practice of markup”, especially as practiced in pervasive, shared XML vocabularies. Each culture, formed in the confluence of people creating, using, and interchanging documents, is both large and quite separate from the standard, specification , or recommendation that defines the tag set. The culture defines the customs and rules about how to interact with and use the tag set. This culture includes mentors and consultants, documentation, webinars, discussion lists, courses, books, conferences, recommended practices and examples, as well as shared tools. Shared tools may be available for both tag set and document creation and editing, document processing including format and display, validation and rules checking, and much more.

The needs of those groups, and the changing needs of the various members who have joined or left these activities, have shaped the tag sets. Things the membership, or the sponsors, or the most vocal/powerful members, think are important are enabled and/or emphasized. (For example, we are seeing more and more tag sets providing the ability to enhance documents with Accessibility information as access becomes more important in the world in general.) How the movers and shakers think influences and molds the tag set.

Conversely, shared tag sets, and the assumptions that underlie them, shape the world view of their users. Before HTML it was common to build tagging structures that allowed paragraphs to contain lists; these days that is considered surprising.

Many of us have bought into the OHCO (Ordered Hierarchy of Content Objects)Renear, Mylonas, and Durand 1996 or “all the world is a tree” model, because XML does those things well. Before SGML and XML it was not unusual to discuss how to identify, markup, and work with the overlapping structures in texts; now it is often considered an “edge case” and thus ignored. To many in the XML world, overlapping structures are simply unthinkable; we have tree-shaped scars in our minds from working with tree-shaped structures. This does not mean that there aren’t significant applications that have, and need, overlapping structures.

I have heard “serious XMLers who work with serious documents” dismiss the “overlap fanciers” as airy-fairy academics who don’t need to get “real work” done. It is fun to remind them that standards, aircraft documentation, and military specifications all require strict and accurate change tracking, and that changes often overlap the initial structure of the document.