Re: [xml-dev] What is an XML anti-pattern?

[Marcus Reichardt <u123724@gmail.com>]

Not so easy a question to answer in general. Personally, I'm leaning towards seeing SGML/XML as a pure document representation format, and very little else. That perspective gives you clear guidelines as to when to use elements vs attributes: everything that is rendered/displayed to the reader/user is element content, and everything else (data about how to render) goes into attributes. If your app doesn't have a concept of "rendering to the user", then markup might not be the right choice of a representation format at all.

When XML is used as a web service payload format, then the above rule used to be applicable still for guidance, assuming the service payload is delivered to a browser with limited markup decoration and processing capabilities (basically element renaming, filtering, and attribute inference).

The idea being here that the raw payload, it being text after all, can be inspected by an end user for transparency, can be validated, etc, and the browser merely acting as a pretty printer of sorts. In that model, service payloads could be pasted into the document stream, could be syndicated and mashed up. But it's clear that we mostly don't do browser frontends that way anymore, and have long come to arbitrary computation in the browser via JavaScript (or XSLT before which is also Turing-complete).

The angle of human-inspectability has also led to applications such as signed manifests in e-commerce, to give users strong cryptographic evidence for purchases, banking statements, etc, which I used to find appropriate XML applications as well (though XML signing/canonical serialization may fall by the wayside as support for XML in mainstream stacks such as Node.js and Rust atrophies).

The discussion in the past days and years have shown that there are colleagues seeing XML primarily as a general-purpose component model serialization format that falls out of a marshalling/un-marshalling process when I'm personally seeing SGML's raison d'etre as an authoring format for editing directly using a plain text editor. I think XSD in particular, introducing named content (complex) types and appealing to OOP concepts using derivation/restriction, and with support for idref/keyref is very useful and successful in that space, though I'm not so sure OOP modeling idioms are a good fit for preserving logical information, OOP being an implementation technique after all, personally coming from a background of logic programming a la Prolog and RDF. Also, a grammar-based formalism seems to only make life difficult here. Still, XSD isn't terrible and my above rule doesn't apply in that space (but boy is it verbose; I can type out a DTD by heart, but have to look up namespaces and markup for XSD every single time). There are a number of XML applications falling into this category that I'm very glad that those exist. For example, I was able to import fairly complex 3D models into Blender using .cae (Collada).

But overall, I'm not willing to make concessions in support of that latter use case to the detriment of SGML's primary use case as a text format. I even find it lame that users are turned away in a hostile manner and advised to use XML-centric tools to search/replace XML content in dogmatic fashion almost daily (on eg StackOverflow); it's not the user's fault that XMLers have first simplified SGML ad absurdum, then introduced fscking XML namespaces to result in a shallow markup language that nevertheless can't be manipulated using regexp techniques and other staples of text processing.

What I'm also not a fan of is that the XML community appears to have lost sight what markup was supposed to bring: a stable and well-motivated bona fide text format in the digital age. Think Garamond and other renaissance-humanists and efforts to preserve text of our age. The reality is that we're heading into an infocalypse with very few parties controlling access and collecting clicks, drastically limiting what can be accessed at all, and how. XML dogmatism is of no help here when the vast majority of content is written using markdown and published using HTML, both of which an be tackled using SGML but not XML. Also, I find it rather depressing that even OASIS standards are published on github for network effects that aren't coming, let alone W3C's; when OASIS started life as SGMLOpen.

And yes, sneaking in lexical type systems into XML on top of XSD is an anti-pattern; another anti-favourite of mine is Apple's .plist format and Java's/Spring's old XML configs; as pointless a use of XML as it gets, giving markup a bad rep, and from a day and age where nobody was getting fired for using XML, but that's about it ;)

Best,
M. Reichardt
sgml.io

> Am 12.11.2021 um 13:54 schrieb Roger L Costello <costello@mitre.org>:
> 
> Marcus Reichardt wrote:
> 
>> I know of only few XML applications more perverse than XMI, 
>> the XML serialization of UML, chock full of XML antipatterns 
>> such extra lexical type systems (not DTD/XSD), 
>> <field name="name" value="value">, and so on.
> 
> Marcus, what is an XML anti-pattern? Are you saying that this:
> 
> <field name="elevation" value="12000"/>
> 
> is an anti-pattern, whereas this:
> 
> <elevation>12000</elevation>
> 
> is not?
> 
> Does anti-pattern mean bad/undesirable? So this:
> 
> <field name="elevation" value="12000"/>
> 
> is a bad/undesirable way to write XML, but this:
> 
> <elevation>12000</elevation>
> 
> is a good way to write XML?
> 
> /Roger
> 
> 
> _______________________________________________________________________
> 
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
> 
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>