More than just a format for recording and encoding data, I found XML came with many neat ideas that changed my approach to processing and handling data -- particularly when combined with the declarative transformation language, XSLT.
I was initially exposed to XML when the standard was in its infancy. One of the products I managed at Adobe, FrameMaker, had strong support for SGML, the forerunner to XML, and so as it rose to prominence I paid attention.
As a general markup language, XML can describe just about any data type. In the document authoring and publishing realm (where FrameMaker was a player), use of XML (like with SGML) encouraged a few best practices. One was the idea of completely separating content from its formatting method. For example, a heading would be tagged in XML as a "heading", but how it would be rendered (bold font, underlined, at the top of a new page, etc.) would be specified in an independent style sheet. This meant that the look and feel of a document could be changed quickly without having to modify the underlying content. The idea could be taken to extremes, by having style sheets for printed documents, online help, cell phone display and web all render from a single source. This idea was central to efficiently implementing the concept of "multichannel publishing".
Another good idea was that document content, although rendered in a serial fashion on a page (i.e. written left to right, from top to bottom), could have an underlying hierarchical structure. This allowed users to manipulate their content in logical elements: grab the chapter, and all of its sections and subsections; grab the entire list, not just a list item, and so on. This hierarchical perspective paved the way to better structure content for the reader, and to make translation workflows much more efficient. Thinking in this hierarchical manner has helped me tackle many problems, beyond the traditional document.
I liked the idea that elements in XML can have attributes, in addition to a basic tag name. The idea of embedding important meta data at the right level of granularity in a body of content is very useful when needing to automatically process that content later. An example would be to have an attribute on each answer to a multiple choice question that represents a given number of points (e.g. best answer gets 5 points; OK answers get 3 points; bad answers get 0 points).
And finally, I liked the idea of having an XML schema. The schema is a set of rules that describe permitted (and required) document structure, element tagging and attributes. In document authoring, the schema can help the author right content in the desired structure. For example, encouraging adherence to the rule "all sections must start with exactly one heading, followed by a paragraph, and optionally more paragraphs, lists or illustrations". This "guided editing" proves to be a valuable way to encourage human writers to create rich content that can be subsequently processed by programmatic means (for example, turning a printable multiple-choice exam into an interactive quiz).
Closely associated with XML is the transformation language XSLT. XSLT has a steep learning curve. But once understood, it permits elegant pattern-matching programs to be written that can do remarkable things with XML documents (in particular, injecting formatting codes for rendering content). I was drawn to XSLT in part because it reminded me of functional programming languages that I learned at University. It seemed very satisfying to use tail recursion and other techniques to elegantly control the processing of repetitive or nested data structures.
XML isn't always the optimum way to represent data or documents. And even when XML is in use, XSLT isn't always the best choice of programming language. But even when they are not used, having an understanding of the basic concepts sometimes helps me look at programming and data processing challenges in helpful new ways.