Now, the eagle-eyed and persnickety among (amongst?) you may have noticed that that title contains "why do I care", instead of "why should you care". That's because this post is different from the usual posts in which something catches my eye, I read about it and then I advocate/motivate for/against my readers caring about that particular thing. In this one, I'm stating why I care about it, without expecting that anyone else does, since maybe a total of seven people (at last count/estimate) responded positively to each of my posts about my intentions to start a vlog on Youtube and podcast on Fountain. (I haven't actually checked my followers count from within Fountain yet today; I've been too busy raking in Nano and fighting twat waffle control freaks hell bent on stifling freedom of speech on TipNano, again, as you may have seen.) Anyway, that's beside the point, perhaps. Let me focus on the topic at hand, which is OPML.

What is Outline Processor Markup Language (OPML)?

Well, that's simple. It's a markup language that lets one export metadata about a podcast (a "channel", in YouTube's terminology) from one site/app and import it into another. It enables this by defining a standard set of terms/tags (a markup schema) that a number of different apps support. iTunes is one of those apps, as it turns out (although I'm not sure if that's only on the import end or if I can also use it to create a podcast and publish/upload content to it; I still need to find something for that, perhaps Hindenberg and/or Stream Yard). I'm not sure why it's "Outline Processor" instead of "Open Podcast", which makes more sense to me.

Anyway, it's implemented as a subset of eXtensible Markup Language (XML). Does anyone remember than clunky old verbose monstrosity from the days before JSON was a thing? I do! It was supposed to be the Next Big Thing that was supposed to revolutionise not only Web Development, but communication and data transfer as well. I learned it, then eagerly awaited whatever would come along and render it obsolete. That new tech is/was JSON. To be fair, there are cases where using XML is arguably better than using JSON, but the number of them are vanishingly small, so small in fact that I can think of only one.

An Anecdotal Digression

The aforementioned case was (I hope now past tense and not still present tense) a rather esoteric hodge-podge of cached data for the administrative interface section of the customer-facing reporting Website for the last corporation at which I worked. The kicker is that it should actually have been in a file instead of a TEXT column in a DB. (It was a file-based DB at that, bien sûr, because why on earth would you use a server-based one for your Website that's accessible to your global customer base of hundreds? What utter madness that would be! When it locks up tighter than a beaver, we can just ping Tech Support to restart the whole server!) However, nobody had refactored the related code to transition it away from that (either the file DB or the chunks of XML therein) because nobody was sure it was actually used and/or too scared they'd break it if it was. (This was in the days when they used archive zips on a NAS of HDDS in the server room for backups, instead of learning to use git for version control. Why use someone else's method when you can ignore industry standards and use your own?) Ditto the peculiarity of a .json file that had JSON objects in the file, but couldn't actually be parsed as valid JSON itself. Then there was the .ini file that was actually a Java .properties file, which doesn't use INI conventions and was, therefore, could not be parsed as a valid INI file ... (This was all the work of a guy who'd mastered the art of getting something to perform and banged out quickly so that he'd meet incentives and get bonuses, but would then limp along wretchedly for far longer than it deserved to exist, because sales and murketing sold it without understanding how technically deficient it was, saddling R&D and Tech Support with the burden of sustaining it.Here's the clincher: He was the head developer/team lead for a long time, not just some newbie script-kiddy hack.

I inherited most of his projects, being the most junior developer. Ah, such fun and heady days those were! I sure don't miss them!) Welcome to Fear-Driven Development (FDD) Using Convoluted Coding Practices to Piece Together a Somehow Functional Product (UCCPPTSFP) 101, folks!

Did Yahweh/Yehowah smoke Cannabis when he made the Platypus? No, because he's fictional. Did CHB (as I knew him, from his changelog.txt files), though, when he wrote code? I'm pretty certain of it.


Right, I think that's enough digression for now. Back to the subject of OPML!

Like What does it Look?

According to Wikipedia, it has the following structure (with example data for if I had an existing podcast shown in italics):

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<opml version=1.0"> <!-- root -->
  <head> <!-- contains metadata, all of which is optional and may be ignored -->
    <title>Snark Attack: Random Musings from the GWS</title>
    <dateCreated />
     <dateModified />
      <ownerName>Great White Snark</ownerName>
      <ownerEmail>[redacted]</ownerEmail>
      <expansionState >collapsed</expansionState>
       <vertScrollState />
       <windowTop>10</windowTop>
        <windowLeft>10</windowLeft>
        <windowBottom>10</windowBottom>
        <windowRight>10</windowRight>
  </head>
  <body> <!-- contains the outline, of which there must be at least one -->
   <outline content="description" text="The one and only Great White Snark's personal podcast, where anything goes." />
    <!-- May contain any number of arbitrary attributes. Common attributes include text and type.
      The outline element may contain any number of outline sub-elements.
    -->
  <body>
</opml>

How horribly verbose and ugly is that monolith (and not just because the code editor functionality is playing silly buggers yet again, reducing it all to glaring red)? JSON would be far more compact and cleaner! (Also, if you're fellow nerd like myself, I suggest reading the "Criticisms" subsection of the Wikipedia article on why the outline and expansionState elements are faulty and often lead to a complete mess. In practice, OPML is anything but standard, since each vendor puts different attributes in the outline, or uses a certain set differently to others.)

Hmm, it seems to me that that anecdote about "Using Convoluted Coding Practices to Piece Together a Somehow Functional Product" wasn't so much a digression as foreshadowing, after all. Now I understand *why* it's "Outline Processing", not "Open Podcast":  It's outlines all the way down, a bit like turtles.

Why do I care?

That's simple: Using OPML will allow me to create a podcast (at some point once I've first found the right app/site that allows me to do so and supports OPML export), export that and then import it into the fountain.fm app, thus avoiding having to go through Spotify, which I detest and refuse to support in any way. Plus, I get to use an open standard in the process of snubbing Big Tech. To me, that's not only shoving in the knife, but twisting it also (not that Spotify will even notice or give a Flying Scotsman if it does, but it gives me some satisfaction to show them my middle fingers anyway).

What's next?

For me, the obvious next steps are these:

• Actually find something that allows me to get a podcast up and running and that I like
• Create my podcast, with a title, artwork  and description.
• Create/export the OPML for it and import it into fountain.fm
• Claim the podcast through fountain, so that I and any listeners I might acquire can earn sats from it.
• Shamelessly self-promote it to all and sundry until I have followers on both the original platform and Fountain.

Thumbnail image: Photo by Marcus Herzberg on Pexels