Some of my friends had mentioned adding RSS to their static site generators was hard; how about turning your index page into the RSS feed, and letting browsers generate the HTML for you?

This feed indeed has some interesting things, related to SCP, sci-fi (especially time traveling), or programming. I bookmarked the Perl introduction, if I ever want to learn Perl and scare my fellow Python developers at work.

Some of my favorite things with Pale Moon include turning it into Netscape, sync support, and built-in RSS preview and subscription support via Live Bookmarks. I however have an issue with the RSS preview: it allows you to subscribe not only via Live Feeds but also with other desktop applications that you might have installed, such as Thunderbird, or Yahoo. My issue is that I wanted to add a button to quickly subscribe on envs.net's TinyTinyRSS instance, and after various attempts I could not add it in the user interface.

Here comes the trusty about:config to the rescue! Looking up yahoo in the configuration values pointed me to two keys in the configuration:

browser.contentHandlers.types.0.title

Initially set to My Yahoo!, I changed it to TinyTinyRSS.

browser.contentHandlers.types.0.uri

Initially set to https://add.my.yahoo.com/rss?url=%s, I changed it to https://rss.envs.net/public.php?op=subscribe&feed_url=%s. I found this URL by looking at the bookmarklets configuration in TinyTinyRSS and reading the short JS code that redirects you to TinyTinyRSS.

I initially tried to add a button next to the My Yahoo! one by creating two new keys, .types.1.title and .types.1.uri, but that failed. I did not yet look into the Pale Moon source code to see why this could have failed.

With this change, instead of Yahoo, I can quickly subscribe to anyone's RSS feeds faster than ever. This will definitely not help my backlog of 2600+ articles…

<xsl:value-of select="description" disable-output-escaping="yes" />

disable-output-escaping is optional according to the W3C specification since version 1. libxslt, Chromium and Internet Explorer do support it, but Firefox chose not to, and a Bugzilla ticket for it will celebrate its 20th birthday this year. They do say themselves that this causes issues for RSS support, so I chose to just not care about it. If you are a Firefox user and are seeing raw, unparsed HTML tags in there, I can only suggest using another browser, or just subscribing to this feed and reading this in its home, a RSS aggregator.

https://www.bbc.com/weather/2644080

Take this integer suffix, which is the ID of the location, and put it in one of these two URLs to get some RSS feeds:

• 3-day forecasts: https://weather-broker-cdn.api.bbci.co.uk/en/forecast/rss/3day/2644080
• Latest observations: https://weather-broker-cdn.api.bbci.co.uk/en/observation/rss/2644080

This procedure is documented exactly like so on the BBC help pages!

Replace rss2 with atom for an Atom feed, and with rdf for an RSS 1.0 feed.

I added a distinction between RSS 1.0 and RSS 2.0 in ITSB and used it to provide more official feeds from the Antigua and Barbuda Department of Marine Services and Merchant Shipping Inspection and Investigation Division and the mongolian Air Accidents Investigation Bureau.

Most people just make blogs on there, called gemlogs. Those gemlogs are frequently practicing a habit that has been disappearing from blogs faster than the blogs themselves disappeared in favor of social media: posts that reply to other people's posts.

I like email as a discussion method because it works like letters, just with some faster delivery and cheaper postage cost; no typing notifications and no expectations of a very fast reply like on instant messaging platforms, so you have less anxiety and more time to write out your thoughts. the UI of most email clients encourage you to write more, to not just send one line; the text length limit probably exists due to technical limitations, but you wouldn't be able to reach it without writing book after book in a single email. twitter is probably the worst place to debate on, since having much less space to explain yourself means your thoughts immediately get misinterpreted.

Replying to other people's posts on your own blog or gemlog is basically like e-mail, but the discussion can be read by a lot more people. you get all the benefits of long-form writing and asynchronous communication, combined with sharing with or receiving knowledge from your readers and other people's readers. However, you can hit an issue where the person who posted the text you replied to might be completely unaware of your reply, and might never read it, unlike email. some standards exist to help with this, such as Webmentions, or the trackback namespace for RSS.

I will let you click the link to read more about trackback; because I am posting today to show you an alternative, if you want to use something that approximatively nothing supports: mod_annotation, a proposed RSS 1.0 module. This, like most RSS 1.0 modules, never reached a status of standard module and disappeared from the Internet, so the only way to find them now is to use the Wayback Machine. I love the Wayback Machine.

To use this module, first add a new XML namespace to your feed: xmlns:annotate="http://purl.org/rss/1.0/modules/annotate/". Then, in the <item> tag, add the following tag to reference something else:

<annotate:reference rdf:resource="https://envs.net/~lucidiot/rsrsss/"/>

This module was only proposed for RSS 1.0, but most feed readers barely make any distinction between RSS 1.0 and 2.0, so if a feed reader ever supported this module, you could probably use it safely in RSS 2.0 too.

Turns out RFC 4685 defines an XML namespace one can use to define replies. It is rather similar to yesterday's mod_annotation.

To use this namespace, you will need to first add the namespace to your feed: xmlns:thr="http://purl.org/syndication/thread/1.0". You then have access to two new elements and two new attributes, and the spec also defines a new rel value:

• <thr:in-reply-to> to indicate what you are replying to using the ID indicated in the <id> tag;
• <link rel="replies"> to point to a page where some, or all, known replies to a post are listed;
• thr:updated to add on the above link the last date when the page was updated;
• thr:count to add on the above link the number of known replies listed in the linked page;
• <thr:total> to indicate the total number of known replies, as the linked replies pages might only contain a portion of them.

None of those are required. You can repeat the <link rel="replies" /> as many times as you might need, if you have multiple pages. The metadata given by the <thr:total> element and the thr:count and thr:updated attributes is non-authoritative, which means it does not have to be exact.

If you are using <thr:in-reply-to>, it is recommended to also include the post's link in a <link rel="related"> to allow a graceful fallback for feed readers that might not support the threading extensions.

The RFC includes a bunch of examples that should be enough to get you started should you ever want to try using this namespace.

Some other formats

Before I start writing posts on threading for just every single syndication format, here is some info for two formats I have experimented with in ITSB:

JSON Feed does not have support for threading in its spec, but you could just make your own extension for that. It does not use JSON-LD either, which would have allowed for a similar extension system as XML; but after experiencing the complexity of JSON-LD first hand at my day job and facing the numerous interoperability issues that causes, I can definitely understand that they wouldn't want to.

Channel Definition Format allows for nested channels, so you could at least create a structured representation of a thread as a tree if you, the original author of the post, knew about all the replies. You cannot, however, specify that you are replying to something yourself. The format does support XML namespace extensions, so you could use thr or mod_annotation.

I recently translated some Japanese specifications I found on the Wayback Machine for two obsolete syndication formats. I first had to determine which encoding the specifications were using, because Google Translate was really unhappy with that; I had to convert from Shift-JIS to UTF-16 then to UTF-8, and from EUC-JP to UTF-8. I am using Google Translate because I know absolutely nothing about Japanese; I just take the messy "English" translation and turn it into comprehensible English.

I first translated HINA, a format that relies on RFC 822 message headers and was designed for Asahina-Antenna. It appears that in Japan, feed readers were called "antennas". This format is apparently still served by some websites according to a quick online search; I will look into that later, just as I will look into those antennas.

Today, I translated LIRS, a format that uses a gzipped simili-CSV to report the same thing.

These two formats do not have item descriptions or optional URLs; they are only meant to report changes on external content. They already take into account the notion of feed aggregation. HINA even has image-related data for photo galleries.

It is pretty hard to trace those formats, first because of the rather obvious language barrier I am facing, and second because the Wayback Machine did not always catch everything, so there are many dead links. Of course, everything is completely dead today. I am however going to keep looking into those formats, and they will soon be implemented in ITSB just for the sake of keeping them alive.

Friday postcards are a concept made by ~jumblesale on tilde.town in which you share a URL to an image along with "#fridaypostcard" (and optionally a comment) on IRC, and a bot picks it up and builds an HTML page every Friday.

An archive gets generated each week too, but there was no easy way to get postcards in my RSS reader and I had found multiple issues in the way URLs were handled, causing some Imgur URLs to not work among other things. I at first had copy-pasted the original script, but then rewrote it to handle those errors and get every single postcard ever made into one W3C-valid RSS feed.

You can browse the script that generates this feed on tildegit.

A few months ago, ~netscape_navigator showed me his "recent reading" list, for which I requested an RSS feed. He uses it in an interesting process to feed on the news while driving using text-to-speech, and just decided to publish his curated news feed. I now generally see this feed as my "wholesome news" feed, because most articles on there are about interesting scientific discoveries, hacking projects, tech history podcasts and articles, etc. There still are some bad news but they are much less related to current politics or other issues of the tech industry like e-waste, america-centrism or racism.

You could probably argue this is kind of a circle jerk, since I am only reading the news from my friends who are more likely to share the same opinions as me; but this feed does not really have that many news, and I am already well aware of the most important issues in tech since I will still see them being discussed on IRC, tilde.news, Misskey, or at the workplace. They are discussed enough for me to just not want them to pollute my RSS reader as well, a place where I can go with the expectation to either relax or learn things. Having this feed here helps me get more interesting articles from lesser-known English-speaking news websites that I simply never heard of in France, such as Scientific American, or discover new blogs.

You can also view the articles in a browser, but why would you do that when you have an RSS reader?

Updates are pretty rare, but it still an interesting feed to have; on the rare occasion that a new article gets there, you know you're in for an great read.

If you register for an account, you can save your searches and then either create email alerts about any new publication in the search results, or get an RSS feed of it. I use that to follow various terms like bookmark, postcard, calendar and USB: I know some people who collect bookmarks, the free postcards they make give me nice illustrations for my notebooks, the calendars usually are large A0 posters so I can fill my wall with them, and they used to offer three publications in the form of USB drives, so I stay on the lookout for that. I should probably also add notebook to the lot, because I have a drawer full of free notebooks. My very first Bullet Journal was started on one of those books.

The website is supposed to only allow you to order one free copy per email address (or per account if you registered, since you can also order without registering), and you will need to confirm your email address if you order as a guest. Since some mail providers like Gmail let you get away with putting dots or dashes in your address and will redirect to your actual email, you can actually get much more from a single address; I was using only the dots and counted in binary to get all the possible unique combinations of dots while ordering a hundred USB keys or nearly a hundred notebooks. I got them all, in a hundred separate envelopes. That was a lot of fun :D

This good friend has built his own static site generator, and built a few more, and we sometimes joke that all that he does is build site generators instead of writing actual blog content. But his feed (and thus his blog) sometimes fill up with some interesting articles anyway. You can in particular get some great examples of well written documentation if you want some inspiration to make this often overlooked part of software development a little nicer in your own projects.

Escargot is a project to revive all of those clients and extra tools, and bring them back into 2021. It is already currently possible to talk between MSN and Yahoo Messenger, and there are plans to maybe, in the long term, support Matrix, XMPP, IRC, or AIM (which already has a server from another project called NINA), to really bring together all of those messaging services.

As I have been occasionally using a Windows XP laptop as my daily driver for a few days each time, I have kept a MSN Messenger 7.5 instance running. Just one friend got in touch with me using it, but I just like to see it being online in my notification area anyway. I also have installed Mercury Messenger on my phone so I can really stay online on MSN all the damn time. If you want to reach me there, and somehow manage to get an Escargot account and a compatible client installed, you can find my Escargot ID on my contact page.

I just discovered today that Escargot has an RSS feed for its recent news, Escargot Today. And it does not just include the last 5 or 10 posts like most blogs do, this feed just has every single news entry since 2017, which is neat. There are not that many updates since most of the project's true activity is on their GitLab repo, but if you plan on playing with this client, this feed will make sure you don't miss out on any breaking changes they might make. You can also access that page on newer versions of MSN since they changed the MSN Today URL to point at their site.

Back when I was using Pale Moon, I could not find out how to add a new option without removing the existing ones so I just overwrote Yahoo with TinyTinyRSS. But this time, I got it to work with an extra setting! Here is the configuration in about:config that I managed to use for SeaMonkey:

browser.contentHandlers.types.6.title

TinyTinyRSS

browser.contentHandlers.types.6.type

application/vnd.mozilla.maybe.feed

browser.contentHandlers.types.6.uri

https://rss.envs.net/public.php?op=subscribe&feed_url=%s

This particular feed is a free newsletter about space exploration from an Indian writer. He initially had two newsletters, Space Impact and Moon Monday, but they got merged into one. I initially discovered this blog through Moon Monday, a weekly report of everything that is happening related to our exploration of the Moon. The goal of this weekly report is to show that exploring the Moon is still on the table and that we still have a lot to learn about it. Things happen quickly enough that posting once a week is indeed necessary.

The reporting is generally pretty comprehensive, despite a noticeable bias against ISRO; the author regularly criticizes his own country's space program as it is often opaque or makes bad decisions. I would like to see more of this critical thinking applied to all the other reported events (which are usually only shown as facts, without much commentary), as there are a lot of issues with Artemis, the American lunar base program, and with ILRS, the Russian and Chinese project.

NASA going fully commercial on the base, all the way to calling for proposals on spacesuits, vehicles that transport astronauts between their training building to the launch pad, rovers, communication satellites, etc., and potentially allowing companies to mine the Moon, means NASA is bringing capitalism to space along with all its issues. Roscosmos' space budget is being slashed by Putin, because they did not achieve their set objectives in time—obviously, less budget will mean they can do more next year. And China's space program had a lot of issues, since rocket parts sometimes fall onto inhabitants (a huge no for absolutely everyone else), and most of what we know about the program comes from leaks.

But I would never have learned about all of these issues without having this blog as a starting point, teaching me about the current state of the space industry and scientific community, which have been completely transformed in the last few years. So if you are interested in learning more about space and what we're planning about it, I cannot recommend it enough.

With those screenshots, I had found some software a few months ago called PlantStudio and it is impressive. There are some screenshots I haven't really exploited yet, mostly of Japanese software. I really am fond of exploring the Japanese web, be it through some of their attempts at creating internet standards like HINA or through the software they created.

Speaking of, It makes me a little sad that Japanese websites are slowly switching to the more "modern" designs we see now, like flat design, and are not keeping the condensed, efficient looks they had before. I used to browse Pixiv regularly, and while its new design is a bit more useful to English speakers, I had gotten used to knowing from memory what each link was in Japanese in the old design and the new one made me lose a ton of features. I wish we could just all go back in time and destroy JavaScript to prevent all of this.

The feed is currently broken due to improper XML quoting, and the repo is being moved from another Gitea instance that has had serious technical issues for a while, so it is a bit messy. I opened an issue to get it resolved.

This feed is from a newsletter than also offers an RSS feed and fax delivery. Its author mostly focuses on the history of technology on various subjects, and has taught me as many things as the previously mentioned 365 RFCs project.

I wasn't really expecting to be able to keep up posting some things to this feed for a whole year, especially considering that I have multiple other websites to take care of and that this year has been hectic.

I still have a pretty long list of things I would like to post about, more interesting posts that just throwing a feed around at random. Let's admit it, when I post a feed, it's just to keep posting regularly when I just don't have the time.

I have been posting about some of my programming projects over on my French blog, and I have been thinking about posts on RSRSSS or on feeds in general later this year. This might give me some fuel to post more on this meta-feed. For now though, I'm posting about parsing geospatial data, and I'll follow that with a dozen articles on some reverse engineering I've been doing. There are so many posts I want to write everywhere and I have so little time and energy…

I have no idea who is even reading this feed since I don't have any stats and I don't want any, but if you've been reading this for the whole year, well thank you very much. Let's hope RSRSSS stays up for another year!

There are many tools to generate RSS feeds from HTML pages, and some of them might just be point and click and they might work for pages that are relatively simple. Some work by looking for semantic HTML tags like <article>, or some require you to write some CSS or XPath selectors or just do some code. But my favorite kind of tool is some program or website that is dedicated to serving RSS feeds for some particular websites, for which feeds are regularly asked for but the devs are refusing to. I guess this somehow falls under the category of adversarial interoperability. Providing an RSS feed for a website against its publisher's will is one of many ways to prevent it from being a completely closed environment, and force it to fit the philosophy of the web, which is to share.

I have done a few of those feed generators over time, and I even published one of its feeds on here. But I had yet to see someone in my Internet circle do something similar. @codl, a cool friend, made Feedplz, a service that provides RSS and Atom feeds for FurAffinity and SSP-Comics. If you are interested in those websites, definitely check this service out and give codl some love.

It's always great to see someone other than me show some interest in feeds, especially to the point of creating new feeds. This service might not have the most well written Python code, or might break easily should any of those websites choose to change something, but it has the merit of existing and of being a reminder that feeds do exist and that some people want them. Just that alone gives me warm fuzzies.

• HTML view
• An OPML export of all the subscriptions
• An Atom feed combining every subscription
• A twtxt feed combining every subscription

While the Atom feed feels a little crude to me, a constant abuser of XML namespaces inside of feeds, I like the idea of what is basically a static site generator whose content comes from feeds. Static sites always feel much more manageable to me, be it as a developer, as a server administrator, or as an archivist. I do have an archivist side, with how much I've been using the Internet Archive in all my projects.

DeviantArt is not aimed at developers but deviants (I guess they're both devs?) but still provides some RSS feeds. With their recent redesign, they have been doing away with most of their comfy and featureful interface to replace it with some laggy experience that's inconsistent with its own mobile apps. Every switch back to a page that still uses the old UI is a breath of fresh air.

One of those pages is the RSS feeds documentation, which also makes me a little worried that they might do away with RSS feeds at some point. They still do serve RSS feeds anyway, allowing you to search for deviations or journal entries. The feeds use Media RSS, which could make them usable on a Playstation Portable if you know how to work around the SSL issues. There is one base URL for all of the feeds:

https://backend.deviantart.com/rss.xml

The query parameters for the feeds are pretty poorly documented, so here is my attempt at it:

limit

How many items to return at once. Defaults to and cannot exceed 60.

q

Search query. When omitted, the feed will return the most popular results. The search syntax is partially documented on the official help center. Additional operators that are not documented on this page include:

boost:

The only known value is popular, to sort by most popular.

by:

Synonym for the officially documented username:. Filters by the name of the submitter.

gallery:

Synonym for the officially documented username:. Filters by the name of the submitter.

location_tag:

Filter by a location tag.

in:

Filters by a category. Category names here are pretty poorly documented, especially since DeviantArt is doing away with categories, but they seem to all have a name only in lowercase and with no spaces. For subcategories, use a slash as a path separator: digitalart/drawings.

sort:

Change the sorting mode. Values are that are known to work include:

popular

Sort by most popular first.

time

Sort by most recent first.

This filter overrides both boost: and special:.

special:

Special filter? I don't know, it's pretty redundant. Known values include:

popular

Sort by most popular first.

newest

Sort by most recent first.

critiquable

Only include deviations that accept critiques. Now causes an HTTP 500 error.

Any other value seems to cause an HTTP 500 error.

subject_tag:

Filter by a subject tag.

tag:

Filter by a tag.

offset

Offset to start at, for pagination. Defaults to zero. You can also use the <atom link rel="next" /> tags to get pre-made URLs for the next page.

order

An integer controlling the sorting. This is overriden by any sorting options specified in q.
It seems that the only two valid values are 9 for most popular, and any other integer for newest.

type

Type of items to retrieve. Values that are known to work include:

• deviation (default)
• journal

Some of those query parameters were found by digging through a million URLs archived by the Wayback Machine using their CDX server.

If you have any further knowledge that should be added here, feel free to contact me.

The project has been much more silent since the pandemic, and there have been no news at all on whether or not it will be coming back, so for now this feed is quite inactive. However, the history there is pretty interesting to read still.

Since this is a WordPress blog, you can also get the Atom feed or the RDF Site Summary feed.

So if you have been coding in PHP, ASP.NET, or ColdFusion, you will now know that you have been writing nothing but RSS feeds the whole time!

I couldn't find out what truly is the .sfm file extension, so if you know about it, please let me know.

I guess having that Atom feed was quite predictable, considering that Atom has been standardized in RFC 4287. Also note that RFCs should now be written using a specific XML format, also defined in another RFC; RFC 7991 being the current version. It feels quite strange to me to see such "high-level" formats in an RFC; I am more used to seeing RFCs about lower-level protocols like TCP/IP or BGP.

For example, you can check out the RSS feed and the Atom feed for my profile on tildegit.org, the Gitea instance hosted by and for the tildeverse.

This is a nice first step, though I feel that user feeds are among the least useful of all the feeds that most common Git platforms provide. As I also maintain Alpine Linux packages, help manage breadpunk.club and manage my own server at home, the feeds that would matter the most to me are the tags or release notes feeds. Those feeds are the most efficient way to be notified of any new releases on most software, and I have opened some issues in the past to ask some maintainers to use Git tags just so I can use the feed.

There is an issue for global feed support, and it is on the 1.17.0 roadmap. I subscribed to it, using the unfortunately email-based GitHub notification system, and will definitely follow it closely.

Most posts are just random automated posts made by bots that were created to convert RSS feeds to ActivityPub, but sometimes I can find some nice things. I got the opportunity to mention HINA at some point, and this week I found a new feed to add to my reader, Grab Free Games. The website's goal is pretty simple: tell you about any Steam games that are temporarily available for free, so that you can add them immediately to your Steam library and them prompty forget about them and never play them. Truly an amazing tool!

If you are more of an IETF fan, you can also get an Atom feed.

I could go and ask for some enhancements to error reporting on all feed readers, but that would be extremely exhausting, as most work in open-source projects feels to me—I definitely am not great at communication. Instead, here is a small initiative that RSS feed developers can make to make the internals of their RSS feed generation system more visible and, for a user that is curious enough to be reading the feed's source, point directly to where they can complain at.

One of the approved RSS 1.0 modules, mod_admin, also called the Administrative Module, defines an XML namespace, xmlns:admin="http://webns.net/mvcb/", and two extra tags you can use:

<admin:generatorAgent>

Should use an URI in a rdf:resource attribute to point to the feed generator. This is redundant with the RSS 2.0 <generator> tag, and the W3C Feed Validation Service will complain if you use both tags at once, but with this new tag, you can specify a URI instead of some arbitrary string, which could let a feed reader make a link available more easily.

<admin:errorReportsTo>

As above, the rdf:resource attribute should point to somewhere to report issues with this feed. This is usually a mailto: URI, but you could also point it to a contact form over HTTP. This is similar to the <webMaster> tag, but the W3C validator does not complain about a redundancy here, so you can safely use both.

By adding <admin:generatorAgent> to your feed, you could let some random developer, let's say, me, look at your RSS feed generation code, and maybe find the bug for you. By adding <admin:errorReportsTo>, a tag name that is more explicit than webMaster, with a clickable mailto: link or a link to a contact form, you can make it easier for curious users and random developers to tell you that something is wrong.

It is obviously not that likely that some random user is going to look at the source of the feed when something is wrong, but considering that content syndication over feeds is dying and that most of its remaining users are the tech-savvy ones, it is not impossible.

And if, like me, you are using an XSLT as your <?xml-stylesheet?>, you could add a link to report errors with your feed if someone is displaying it in a browser. If you open RSRSSS in your web browser and your browser does not have native support for RSS feeds, then you can find this link at the very bottom of the page.

As mentioned earlier when I talked about the 1.16.0 release, the feeds are accessible either by setting the Accept header to application/rss+xml or application/atom+xml when requesting a user, an organization or a repository's URL, or by appending .rss or .atom to the username, repository name or organization name. Some examples:

• The RSS feed and the Atom feed for my account on Tildegit, the Gitea instance of the Tildeverse;
• The RSS feed and the Atom feed for the repository hosting RSRSSS;
• The RSS feed and the Atom feed for the Commonhealth of Casakhstan's Gitea organization on Tildegit.

I hope that we will see the feeds for releases in the next release, so that Gitea adds the one missing feature to make package maintainers happy.

By the way, the RSS feed for the RSRSSS repo could be called the Really Simple RSRSSS Repository Syndication feed, or RSRSRSSSRS.

I mentioned reaching 200 feeds on IRC, and ~dozens awarded me a badge for my outstanding feedchievement!

I have quite the backlog of feeds to share on here. Feel free to harass me if I don't post one each week, because I have no excuse.

To use it within RSS and Atom feeds, you will need to add the namespace to the root tag as usual: xmlns:access="http://www.bloglines.com/about/specs/fac-1.0". You can then add the access:restriction element as a child of the root element, with the relationship attribute set to allow or deny. When the element is not set, allow will be assumed. If the feed had previously set deny, removing the element will still cause aggregators to keep assuming a denial; allow must be explicitly set to restore indexability.

<rss version="2.0" xmlns:access="http://www.bloglines.com/about/specs/fac-1.0">
  <access:restriction relationship="deny" />
  <channel>
    <!-- ... -->
  </channel>
</rss>

<feed xmlns="http://www.w3.org/2005/Atom" xmlns:access="http://www.bloglines.com/about/specs/fac-1.0">
  <access:restriction relationship="deny" />
  <!-- ... -->
</feed>

Note that this is the only case I know of where an RSS extension adds a tag outside of both <channel> and <item>.

This Git repo hosts a CSV file exported from dozens' Calibre library. The file is also converted to a recfile, and with my help to an RSS feed. This was set up after dozens shared some of his collection with the casakhstan, and we got interested in it and any new additions to it.

If you are interested in a book found within this library, feel free to contact ~dozens to request one of the ebooks. You wouldn't download an ebook, wouldn't you?

While looking for some sort of authoritative source for the definition of a hypergrid, I found Outworldz, a website full of resources related to OpenSimulator, the server software that runs all of those worlds. Its name seems to be a pun on InWorldz, one of the largest commercial OpenSimulator grids, which has existed from 2010 to 2018 before shutting down and seemingly starting from scratch.

I am quite curious about those old virtual worlds, especially now with all this metaverse bullshit. I browsed around a bit and realized they provide an RSS feed of the LSL scripts shared on this website. LSL, or the Linden Scripting Language, is the scripting language made by Linden Lab for Second Life. Scripting is how most of the virtual worlds come to life; be it enabling automatic transactions, sending messages, embedding YouTube videos to create movie theaters, etc., LSL can become important quite fast if you want to do interesting things in OpenSim. So here it is, a feed that genuinely surprised me, full of interesting content for a community that sounds inactive today, but still definitely exists.

I made my ideas page into an RSS feed after I rewrote the page so it would be generated from a recfile, so here it is. If you have made your own ideas page, feel free to let me know and I'll feature you in the section at the bottom of the webpage.

For example, feeds that just have pretty images don't need much spoons to process, while blogs with in-depths reflections on some topics will take more time to read. I can skim through some feeds while barely reading the post titles, but some other feeds have items that are actual tasks to complete. I have seen various posts about people saying you should weed out as much as you can from your feedreader because you will never read everything, but the point is not always to read everything.

When I was doing my categorizing, I had been asked on IRC about which categories I use and why, so this post is a more thought-out reply.

I am probably not fully done with categorizing, but I got a pretty good list right now. My current list of categories does represent how I use my feed reader pretty well, and over 90% of the feeds have a category right now. Here's a summary of those categories:

Aggregators (10 feeds)

Feeds whose items are mainly reposts from other blogs, or lists of links, etc.; those either send me down random rabbit holes that might lead to subscribing to moar feeds, or I can just skim through them. I usually do a first pass over them when I am going through all of my unread articles just to skip the posts that I want to skip, and leave the more interesting reads for later. I later come back to this category to go through the links and read everything else.

Alpine upstreams (13 feeds)

Feeds for Git tags and releases on GitHub, GitLab or Gitea instances. I maintain some Alpine packages, so I stay up to date on the new releases using those. I only mark those items as read once I have completed the relevant Alpine package's upgrade.

Comics (9 feeds)

Just webcomics; images with usually funny text in it. When I just want to reduce my unread articles count quickly without much thinking, I can go through these.

dozens (19 feeds)

An entire category dedicated to the feeds of just one person. ~dozens has blessed me with the highest amount of feeds from one author. Most of the feeds are from various of his accounts, like on Goodreads, Gitea, archive.org, etc., and I can usually skim through these, but there are multiple blogs in there.

EU Bookshop (4 feeds)

I had mentioned before that the Publications Office of the European Union has an online store that provides RSS feeds of search results. There are a few keywords I monitor, such as USB in case they ever decide to release free USB keys again, so I keep them here.

Friends (25 feeds)

All the feeds from friends other than ~dozens. Quite the hodgepodge of feeds from various online accounts and of blogs that take longer to read.

Images (6 feeds)

Feeds with just some pretty images, and sometimes some interesting facts about those images. Very quick to read through.

ITSB (44 feeds)

A subset of the many feeds I generate in my ITSB project. I like to sometimes read the accident reports I get there, but most of the subscriptions are just so I can check that the feeds appear to be behaving normally and detect errors, so I can just mark the entire category as read if I am not in the mood.

lucidiot (15 feeds)

My own feeds, some generated by my own scripts, and some from my online accounts. Just like ITSB, this lets me troubleshoot them, or at least be aware of what I am sending out to the rest of the world.

Podcasts (3 feeds)

I'm not too much of a fan of podcasts, but some friends have started them, so I keep there separately. They usually require me to have a long chunk of free time available, because I am simply unable to listen to English podcasts while doing anything else, unless I decide to just not try to understand what is being said.

Services (7 feeds)

Status pages or blogs of various services I use, such as Escargot or OpenStreetMap. I quickly read through them just to stay updated on those services and know about any action I might need to take.

Tech blogs (27 feeds)

Various blogs related to programming, electronics, networking, server administration, etc. Categorizing made me realize that I think I just have too many of those, and often don't care that much about the topics in those blogs, mainly because I care less and less about the state of modern web development. Each time I go through those, I take some time to think about whether or not I want to keep the feeds in here.

Weeds (6 feeds)

Short for web feeds, a bunch of feeds made by my friends and providing RSS-only content. Those are much less formal than blogs, post irregularly, and encourage conversations between us since we all subscribe to each other.

Writing (8 feeds)

Anything that could possibly relate to writing, mostly in a notebook, or that invites me to write in my notebooks for any reason. This includes blogs about bullet journaling, handwriting, productivity, personal development, etc., and I would like to have more of those in my reader.

YouTube (17 feeds)

All my YouTube subscriptions. This works a lot better than actually subscribing to a channel on YouTube since you don't have to care about the bell; you will get notified of each video every time. This also means I don't need a Google account for this. I usually go through this category during lunch break when I work from home.

Uncategorized (15 feeds)

Those are blogs that just do not fit anywhere else. Maybe they go on about completely random topics each time, or they would just be the only feed in their category (for example, I could have Transportation and Space with one feed each), or they live at the intersection of two or more categories and I haven't decided where to put them yet. Alternatively, I might just be wondering whether I should still be subscribing to them, so I don't even bother to categorize them.

Some of those categories explain why I am not yet sharing an OPML export of the feeds I currently subscribe to; some feeds have a private token embedded in the URL for authentication, or some are not meant to be shared too publicly. Managing a custom OPML export from TinyTinyRSS would be a bit too much work whenever I subscribe or unsubscribe from a feed. Instead, you'll just get the feeds featured in RSRSSS as an OPML file, as I slowly work my way through my subscriptions or other feeds that I find interesting and share them on here.

There are a few more specific feeds if you want just one category of their posts.

I have been logging my dreams on and off for multiple years in my notebooks. I had intially started that as a quest to do lucid dreaming, a quest that I gave up on because reality checks are a really difficult routine to get into and they weren't bringing much of a result. The lucid in lucid dreaming was the original inspiration for my nickname. I kept on logging my dreams after that because I was still interested in remembering my dreams, and I nowadays also use this as an excuse to write at least one line a day in a notebook, since that is a habit I want to keep; when I do not remember a dream, I will still write I did not remember my dreams.

Getting those random dreams in my feedreader is what got me started in posting my own dream logs on my wiki. I might end up separating them at some point, as I am slowly working my way through all the dreams I have logged over the years in many notebooks, translating them and obfuscating them for public consumption.

My dreams almost always involve me with some family members or friends in a very bizarre situation, but still in keeping with most of the laws of physics, whereas dozens' dreams appear to have a much more malleable world. That might be related to me being much less exposed to fantasy or RPGs and having much less creativity.

dozens, now a recurring character in this feed, summarized me in an original way:

there's an rss devil on my shoulder telling me to make new feeds all the time, and it is lucidiot. on my other shoulder is an rss angel and it is also lucidiot and it is also always telling me make new feeds.
like how in some storylines the joker just wants batman to be the very best batman he can be. lucidiot is the rss joker to my compulsive writing batman.

rssoker: everyone is just one bad day away from making another rss feed
rssatman: you're wrong rssoker
rssoker: HAHAHAHAHAH

This blog is mostly known for its random posts on Microsoft jargon (which Chen calls Microspeak) or various pieces of Windows trivia, such as why Pinball was removed from Windows, and why it cannot come back even though they want to. More recently, a post on a song that made hard drives crash resulted in a vulnerability being reported.

Each status includes an emoji to summarize your current mood or state, and if you know how to use the browser's developer tools, you can make it use any Unicode character you want. You can show off your current status emoji using a badge, and I have put mine among the many others on my tilde.town page.

status.cafe provides a whole bunch of Atom feeds; you can subscribe to a feed of everyone at once or the specific feed of each user as https://status.cafe/users/[username].atom. For example, here is mine.

While exploring the information superhighway to learn more about other feeds I wanted to post about on here, I also stumbled upon imood, which possibly was a source of inspiration for status.cafe. Statuses are called moods, and have both a personal mood (some sentence that the user writes) and a base mood selected from a set. There are no feeds on this one though, so status.cafe is clearly superior.

I am building a small backlog of posts to hopefully allow me to post somewhat regularly, using something even worse than just writing XML by hand as I usually do in here. I created a database using LibreOffice Base on a whim, just because I wanted to play with that one evening, and ended up inserting about 50 feeds that I wanted to post and creating a form to start writing short descriptions of each feed to later post them.

Today, I somehow conjured the energy to rewrite the XSLT that powers the HTML rendering of this feed, on browsers that do not support RSS feeds natively. It looks more refined, and I have some ideas for future extensions such as supporting enclosures, GeoRSS, Event RSS and more. It now also includes some optional JavaScript that fixes the HTML unescaping issue on Firefox, making the feed much more readable. After finishing a first version of this new theme, I decided to finally post again and announce this possible return.

One of the many reasons why i have so little energy to post is that i feel like most of what i do is meaningless or not interesting to anyone, which is probably to be expected when i explicitly choose to ignore SEO or just when i work on very niche topics. if you want to help me fight the negative voices in my head, feel free to reach out to me. Even just a single sentence to tell me you are reading me is hugely appreciated.

I have known about 100r for a while, but only follow them by reading this feed because their creations and ideas are often incompatible with my life; I do not live on a boat and do not really enjoy the kind of very minimalist, colorless aesthetic that they follow. Getting those quick monthly reminders of the existence of the concept of permacomputing, and taking a few minutes to watch those people living in what looks like an alternate universe completely separate from mine, can still be interesting in small doses.

• Every single post
• All posts in one topic
• All posts in one board

It could also have feeds for all posts by a user or all posts within a forum (a group of boards), but having the option of following this messageboard using a feedreader is still quite neat.

There also used to be a vpub instance dedicated to vpub itself at vpub.miso.town, but it appears to be offline now. m15o, vpub's creator, said they are not working on it as well.

The JTS and its C++ port called GEOS power pretty much every geographical information system under the sun. I don't understand much about the math behind GIS stuff, but this blog showcases some of the new features in the JTS with some simple examples. It can help me suggest improvements at work, or get new ideas for weird projects since I like playing with maps now.

This feed is also available as an Atom feed. ]]> Sun, 16 Jul 2023 12:06:35 +0200 planet-osm Feed https://planet.openstreetmap.org/pbf/planet-pbf-rss.xml There are a whole lot of feeds for OpenStreetMap, and since I like both OpenStreetMap and, of course, feeds, I will be talking about a bunch of them over multiple posts. To start with, here's a feed of torrents that you can put into any BitTorrent client that supports feeds, like Deluge, to automatically download a weekly export of the entire map. That would be over 1.7 terabyte of OpenStreetMap XML data, but they provide a better format called PBF based on protobuf, that reduces this down to about 70 gigabytes.

Multiple RSS feeds are available, to get the PBF version, the BZ2-compressed XML version, or the entire history of the map and not just its current state. Those are documented on the OSM wiki.

I really like the name of this thing. Planet. You can just… download the whole planet. This is how far we've come as a society. Why stop at downloading a car when you can download a planet?

Just as I noticed this, it turns out that the board has turned 20 just a few days ago. Happy birthday!

Discovering this also made me find out that Dave Winer is also on the Fediverse, and is just as bitter as he is rumored to be. I guess the old days of the wars between RSS 1, RSS 2 and Atom are still not over.

Probably the most exotic part of this image sharing service is that every image is highly compressed: no more than 400×400 pixels in size, and saved as JPEG with a quality of 5%. This probably makes hosting this service a lot easier in terms of bandwidth and storage space, and makes the images look blurry or less detailed. Most piclog users are status.cafe users, so it's interesting to see the photographic equivalent of the things I see fellow status.cafe users post regularly.

While you can get a feed of every photo from everyone, you can also get feeds for each user, with https://piclog.blue/user-feed.php?id= followed by the integer ID of the relevant user. You can get this ID by opening their profile, since the same ID will be in the profile URL. Here's m15o's feed for example.

As of posting this, the feeds unfortunately do not use Media RSS or embed the image into the description as an <img> tag, so you will have to open each item in your browser to view the image with most feedreaders.

The NTSB is the one investigation agency I really must have in ITSB. It might just be the largest agency for transportation safety investigations worldwide, and anyone who ever watched a Mayday documentary or looked into plane crashes has heard of it. They produce the largest amount of reports out of all the agencies I found through ITSB.

Fortunately, they provided an official RSS feed for their released investigation reports. I'm using the past tense though, because they unfortunately decided to shut it down. The feeds were still available for a little while, but they would be completely empty. I have yet to see anyone ever sunsetting a feed properly, by adding a post to warn everyone for a few days before just killing the feed completely, so this issue went unnoticed for a while.

To generate a feed when there is no official one available, I usually just run curl on a webpage that lists investigation reports, then use pup to select some HTML elements and convert them to a JSON structure, then mess around with said JSON with jq, and finally convert that back into XML using xmltodict. But after looking around on the NTSB's website, I went for a much weirder method.

The NTSB provides a service called CAROL, a tool to search through all the investigation reports and safety recommendations the NTSB ever published. Getting a lot of structured data sounds a lot more interesting than having to parse the scant details I can get from unnecessarily complex HTML pages, so I wanted to use that as my source for my custom feed.

After a lot of experimenting, I ended up writing a separate script that exports 1 year of completed investigation reports as a large JSON file. I could have exported 10 or more years of reports, but that resulted in an extremely large RSS feed that would make most feedreaders blow up, so I only got one year.

I then use a 671 lines long jq script to process this JSON file into an RSS feed, including as much information as I can within the <description> so that you sometimes do not need to read the PDF report at all.

This mess results in a feed that is far, far better than any other feed I have in ITSB, especially any official feed. If every webmaster wants to remove RSS and replace it with newsletters, since that's what I gathered from my few attempts at reaching out to those agencies, maybe the real solution is to push for more open data instead. Let the people who know and use RSS make proper RSS feeds without scraping your website…

A while ago, I tried to look for more blogs related to stationery, handwriting, etc., and I found The Cramped. This blog evolved a bit over time, and nowadays the author occasionally shares other people's posts related to writing, notebooks, writing in notebooks, personal knowledge management, etc. This kind of feed is nice to have if I want to discover more blogs! I subscribed to maybe two or three already thanks to it.

• Their blog posts, of which there currently are none;
• All RFCs in any state;
• Only the adopted RFCs;
• Only the drafts and proposed RFCs.

A coworker suggested that maybe we should have a standard for french tacos, since many places selling french tacos commit blasphemy by adding veggies in them, sometimes even adding them by default without warning you. I have some experience writing joke RFCs, so that's something to consider.

<rss version="2.0" xmlns:icbm="http://postneo.com/icbm">
  <channel>
    <!-- ... -->
    <icbm:latitude>30.0301</icbm:latitude>
    <icbm:longitude>32.5776</icbm:longitude>

    <item>
      <!-- ... -->
      <icbm:latitude>31.5077090</icbm:latitude>
      <icbm:longitude>-82.3115156</icbm:longitude>
    </item>
  </channel>
</rss>

With this method, you can therefore specify a location where someone may send a nuke if they have been particularly angered by something you published on that feed. Or more commonly, you might want to set a location relevant to the feed, like the location of the tautology club whose blog has a feed for, or the location of something mentioned within the feed.

There are other, more recent and more standard methods to refer to geographic coordinates in an RSS feed, and not just specific points. We will go over those some other time.

This is meant to be used in RDF, so you would probably normally use this in a RSS 1.0 feed, but as with many other RDF namespaces, nothing really stops you from integrating that into RSS 2.0 or Atom, and many people have done so already.

<rss version="2.0" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#">
  <channel>
    <!-- ... -->
    <geo:lat>30.0301</geo:lat>
    <geo:long>32.5776</geo:long>

    <item>
      <!-- ... -->
      <geo:lat>31.5077090</geo:lat>
      <geo:long>-82.3115156</geo:long>
      <!-- It's Moon time. -->
      <geo:alt>384400000</geo:alt>
    </item>
  </channel>
</rss>

Two years later, in April 2005, GeoURL.org, a service that used to allow finding websites by their associated geographical location, introduced the geourl namespace, adding another duplicate namespace on top of icbm and geo. I mention it here too because the W3C validator supports all three namespaces!

You can use it with xmlns:geourl="http://geourl.org/rss/module/" and the <geourl:latitude> and <geourl:longitude> elements. I would however advise against using it as it increases the complexity for feed parser and feed reader developers; prefer the RDF geo namespace instead, which is more widely known.

And as a last piece of advice, do not mix the icbm, geo and geourl namespaces within the same channel or item, even if you intend to represent multiple coordinates at the same time! There are more complex but more flexible alternatives, which we will see in later posts, that allow to go beyond a single point.

GeoRSS is a standard that was developed by a mix of geospatial and syndication people and released in 2006 on georss.org. That website is now gone, but of course, the Internet Archive's got our backs. In 2017, that standard got republished by the Open Geospatial Consortium, the gods of geospatial standards, as OGC 17-002r1. I really like that quote from that version of the standard:

The initial goal for designing and documenting GeoRSS was to keep the encoding of geography on the Web from fracturing into various encodings the way RSS ended up, with multiple similar implementations.

Considering that the three namespaces we saw in the previous posts appeared before GeoRSS, and that georss.org mentions the W3C Geo namespace, it doesn't seem like they were starting well. However, the few remaining feeds that I know of that include geospatial information do use GeoRSS only, so I guess they won in the end. The fact that only geospatial experts would be using geospatial coordinates within RSS feeds, and that most GIS software only supports GeoRSS or name all of their RSS support GeoRSS, must have helped.

GeoRSS defines two so-called "serializations", called Simple and GML. In this post, we will only consider GeoRSS Simple; GML requires us to delve deeper into the mess that is geospatial information, so we'll see that at some other point in time. The goal is to have most feed producers, those that are not geospatial experts, use GeoRSS Simple, which is simple enough to be understandable by them, and have geospatial experts use GML, which they probably prefer. You can convert from GeoRSS Simple to GeoRSS GML, but not necessarily the other way around.

Here's an example of yet another way to represent a point in an RSS feed, but using GeoRSS Simple this time:

<rss version="2.0" xmlns:georss="http://www.georss.org/georss">
  <channel>
    <!-- ... -->
    <georss:point>18.5166670 33.6666670</georss:point>

    <item>
      <georss:point>18.5166670,33.6666670</georss:point>
    </item>
  </channel>
</rss>

Where the other namespaces use two distinct tags to represent both coordinates of a point, GeoRSS uses only one tag, which is defined as a list of real numbers. While using one or two tags does not matter much when using GPS coordinates, it does start to matter when you care a lot about altitude or work with other coordinate systems. GeoRSS Simple requires WGS84 (GPS) coordinates and represents elevation separately, so it won't ever matter in this serialization, but with GML, it will!

You may also note that in the first point, I used a space to separate both coordinates, whereas in the second one I used a comma. The official XSD for GeoRSS Simple defines the point as holding a list of doubles (decimal numbers stored in 8 bytes) using the XSD <xs:list> element, which defines a list of items as being space-separated only. But section 7.3 of the OGC standard states that a comma is also acceptable, so anyone wishing to parse GeoRSS will have to take that into account.

<rss version="2.0" xmlns:georss="http://www.georss.org/georss">
  <channel>
    <item>
      <!-- ... -->
      <georss:point>-33.8735580,151.2344385</georss:point>
      <georss:featureName>Boat Syndication Australia</georss:featureName>
      <georss:featureTypeTag>shop</georss:featureTypeTag>
      <georss:relationshipTag>has-nothing-to-do-with</georss:relationshipTag>
      <georss:elev>5.25</georss:elev>
      <georss:floor>0</georss:floor>
      <georss:radius>4.5</georss:radius>
    </item>
  </channel>
</rss>

Here's a description of all of those intriguing optional elements:

<georss:featureName>

The name of the thing you are referencing with that point. A feature is anything that has a geospatial location; a mountain, a country, a single atom, it doesn't matter.

<georss:featureTypeTag>

The type of that feature: whether it is a mountain, a country, etc. When unset, it defaults to location. There are no other defined values, as the intent was to let the community form its own taxonomy.

While neither the original website nor the OGC standard specify any restriction, the official XSD typed it as a QName, meaning an XML qualified name, or anything you can use as the name of an XML element, with or without a namespace prefix. This means you can use something like sandwich:blt, but not food:sandwich:blt because only one colon is allowed, and you cannot use spaces. All examples in both the original website and the OGC standard never use spaces, instead preferring kebab-case. So you should probably limit yourself to a QName, or maybe just to kebab-case.

<georss:relationshipTag>

The relationship between the channel or item and the feature. For example, you could have a feed of sightings of toads and owls where the relationship is seen-at, or a feed of drawings where each drawing was inspired-by. The default is is-located-at. The relationship is always from the channel or item to the feature, not the other way around. It has the same confusing definition as a QName as featureTypeTag.

<georss:elev>

The elevation, in meters, with decimal and negative values allowed. The OGC standard says nothing about this, but this tag does not make any sense with GeoRSS GML since it supports three-dimensional coordinates.

<georss:floor>

The floor of a building, as any integer, including negative values. Since there are two different ways to number floors depending on which part of the world you are in, you'll have to guess which is the correct one!

<georss:radius>

Geospatial people probably know this better as a buffer. This means the location you are actually referencing is anything that is some amount of meters around the coordinates. For a point, this will create a circle, but since we can go beyond points with GeoRSS, this can add more complicated borders. This page has some examples.

Next time, we will finally do more than just point at things, and use the other geometry types that GeoRSS offers.

<georss:line>

In the geospatial world, a line is not just between two points, it's a series of two or more points. In GeoRSS, it is represented by a long list of numbers, always in pairs.

<georss:box>

Two pairs of coordinates, representing the lower-left and upper-right corners of a rectangle.

<georss:polygon>

This is the geometric, and not the geospatial definition of a polygon. In GIS, a polygon has multiple linear rings: one exterior ring, and zero or more interior rings that draw holes inside of the polygon. A linear ring is the more common definition of a polygon: a line that starts and ends at the same point. Here, we can only have the exterior ring of a polygon, so this is actually a linear ring. It is represented just like a line, as pairs of coordinates. There are at least three points per polygon, and the first and last must be equal.

Here are some examples of each of those tags:

<!-- Part of Haaldersbroekerdwarsstraat, a long street name in the Netherlands -->
<georss:line>52.4718867,4.8277792 52.4721926,4.8275892 52.4729501,4.8270419</georss:line>

<!-- Some random grass not so far away from there -->
<georss:box>52.5662344 4.7976189 52.5676983 4.8013674</georss:box>

<!-- A building called ESPRESSO at the Very Large Telescope,
because astronomers need coffee to go through the night -->
<georss:polygon>
  -24.6273416,-70.4045081
  -24.6273922,-70.4044894
  -24.6274264,-70.4046014
  -24.6274789,-70.4045820
  -24.6276119,-70.4045330
  -24.6275341,-70.4042780
  -24.6274634,-70.4043041
  -24.6274763,-70.4043463
  -24.6273109,-70.4044074
  -24.6273416,-70.4045081
</georss:polygon>

You can only specify one of these geometries at once, along with all the optional elements that I described in the previous post. Those new shapes enable some new interesting use cases for feeds:

• Blogging about a cross-country hike, with the GPS track of each day as a <georss:line>.
• A feed warning about upcoming solar eclipses, with a <georss:line> to show where the shadow of the eclipse will be moving on the Earth's surface. Maybe with a <georss:radius> as the radius of the shadow to do some buffering and not only show the center of that shadow.
• A feed of weather reports, with the <channel> including the location of the weather station, or the area where the reports apply.
• A feed of interesting architecture, with a <georss:polygon> around the circumference of each featured building.
• A feed of triangulated radio signals heard by a whole bunch of radio equipment scattered around an area, either as a <georss:point> with a <georss:radius> to show the precision, or as a <georss:polygon> showing a triangle of the receivers that detected the signal.
• A feed for any temporary changes to bus routes and timetables, with a <georss:point> when a stop is skipped or moved, a <georss:line> when a line gets rerouted, etc.

You can probably use any of the geoportals out there, the websites that list open geographical data mostly from governments, and get plenty more ideas for GeoRSS feeds.

And since we are now done with GeoRSS Simple, we'll look at GeoRSS GML next time.

GML is an enormous XML schema designed to express any geospatial data under the sun. Geometries, features, coordinate reference systems, units of measurement, time, sensor measurements, data re-fetched automatically over the network, assigning coordinates to images, etc.

The language is not meant to be used alone, as supporting all of it is equivalent to implementing nearly every bit of geospatial software out there. Instead, GML profiles are defined, which are subsets of GML that are relevant to your needs, and are then used in application schemas, which define the specific XML format you are using that will contain some of that GML profile in it.

GeoRSS is an application schema using a dedicated GML profile that severely restricts GML so that we don't become too insane. You are limited to four geometries, one less that the five we saw in GeoRSS Simple: points, lines, boxes, and polygons. You do have access to some extra options though, and we'll look into that soon enough.

Examples

Here is an example I wrote previously for a single point in GeoRSS Simple, but rewritten for GeoRSS GML:

<rss
  version="2.0"
  xmlns:georss="http://www.georss.org/georss"
  xmlns:gml="http://www.opengis.net/gml"
>
  <channel>
    <item>
      <!-- ... -->
      <georss:where>
        <gml:Point>
          <gml:pos>-33.8735580 151.2344385</gml:pos>
        </gml:Point>
      </georss:where>
      <georss:featureName>Boat Syndication Australia</georss:featureName>
      <georss:featureTypeTag>shop</georss:featureTypeTag>
      <georss:relationshipTag>has-nothing-to-do-with</georss:relationshipTag>
      <georss:elev>5.25</georss:elev>
      <georss:floor>0</georss:floor>
      <georss:radius>4.5</georss:radius>
    </item>
  </channel>
</rss>

The only two differences are that there is now a new gml namespace, and that the georss:point element has been replaced with a georss:where element to hold the point defined with GML. And now for the examples of other geometry types, which you would now place inside of the georss:where:

<!-- Part of Haaldersbroekerdwarsstraat, a long street name in the Netherlands -->
<gml:LineString>
  <gml:posList>52.4718867,4.8277792 52.4721926,4.8275892 52.4729501,4.8270419</gml:posList>
</gml:LineString>

<!-- Some random grass not so far away from there -->
<gml:Envelope>
  <gml:lowerCorner>52.5662344 4.7976189</gml:lowerCorner>
  <gml:upperCorner>52.5676983 4.8013674</gml:upperCorner>
</gml:Envelope>

<!-- A building called ESPRESSO at the Very Large Telescope,
because astronomers need coffee to go through the night -->
<gml:Polygon>
  <gml:exterior>
    <gml:LinearRing>
      <gml:posList>
        -24.6273416 -70.4045081
        -24.6273922 -70.4044894
        -24.6274264 -70.4046014
        -24.6274789 -70.4045820
        -24.6276119 -70.4045330
        -24.6275341 -70.4042780
        -24.6274634 -70.4043041
        -24.6274763 -70.4043463
        -24.6273109 -70.4044074
        -24.6273416 -70.4045081
      </gml:posList>
    </gml:LinearRing>
  </gml:exterior>
</gml:Polygon>

Reference

<georss:where>

The wrapper for GML within an RSS feed. While nothing really stops you from using GML directly without GeoRSS within an RSS item, most feedreaders and other parsers will only support GML wrapped into this element. This should not be used at the same time as the GeoRSS Simple geometry elements like <georss:point>.

<gml:pos>

A single coordinate pair, as two decimal numbers. The first is the latitude between –90 and 90°, and the second the longitude between –180 and 180°, as WGS84.

<gml:posList>

A list of 2 or more decimal numbers representing a series of coordinate pairs. There should always be an even number of coordinates.

<gml:Point>

A single point, containing a <gml:pos> element to indicate its coordinates.

<gml:LineString>

A series of points linked together by straight lines. This should contain a <gml:posList> to list the coordinates of each point.

<gml:Envelope>

A rectangle. This must contain a <gml:lowerCorner> and a <gml:upperCorner> to specify its two corners.

<gml:lowerCorner>

The lower-left, or southwest, corner of a <gml:Envelope>. Its value is the same as a <gml:pos>.

<gml:upperCorner>

The upper-right, or northeast, corner of a <gml:Envelope>. Its value is the same as a <gml:pos>.

<gml:Polygon>

In the GIS world, a polygon is composed of multiple rings; at least one exterior ring, and zero or more interior rings that create holes within the exterior ring. This element therefore must have a <gml:exterior> ring. GeoRSS GML forbids any interior rings, since the GeoRSS Simple <georss:polygon> does not support interior rings, so the exterior ring is always alone.

<gml:exterior>

The exterior ring of a polygon. This should contain a <gml:LinearRing>.

<gml:LinearRing>

A <gml:LineString>, but there has to be at least four points, and the first and last coordinates must be equal, so that the line string forms a ring.

The OGC standard, which is the only currently active standard, and the original archived pages for GeoRSS Simple and GeoRSS GML do not define any specific element to describe a circle. If you want to represent a circle, you can do so using the <georss:radius> element, which will create a buffer around a point.

<!-- GeoRSS Simple -->
<georss:point>-24.62759969859908 -70.40503541618583</georss:point>
<georss:radius>14.74038882</gml:radius>
<georss:featureName>Antu, VLT-UT1</georss:featureName>
<georss:featureTypeTag>telescope</georss:featureTypeTag>
<georss:relationshipTag>has-nothing-to-do-with</georss:relationshipTag>
<georss:elev>2635</georss:elev>

<!-- GeoRSS GML -->
<georss:where>
  <gml:Point>
    <gml:pos>-24.62759969859908 -70.40503541618583</gml:pos>
  </gml:Point>
</georss:where>
<georss:radius>14.74038882</gml:radius>
<georss:featureName>Antu, VLT-UT1</georss:featureName>
<georss:featureTypeTag>telescope</georss:featureTypeTag>
<georss:relationshipTag>has-nothing-to-do-with</georss:relationshipTag>
<georss:elev>2635</georss:elev>

However, the XSD defining the GeoRSS GML Profile, and the one for GeoRSS Simple, both include ways to specify a circle separately. The OGC standard has links to the schemas and does not state that those schemas are not non-normative, as many other specifications do. That means that in theory, it is completely legal to use them.

Reference

<georss:circle>

A GeoRSS Simple circle. Circles are defined by their center and their radius, so three numbers should be used here: latitude, longitude as WGS84 coordinates, and the radius in meters.

<gml:CircleByCenterPoint>

A GeoRSS GML circle. Must be used within a <georss:where> element. This should have a <gml:pos> element to specify the coordinates of the center point of the circle, and a <gml:radius> element to specify the radius.

<gml:radius>

The radius of a circle. This can have an uom attribute to specify the unit of measurement, which is by default m to represent meters.

uom

A unit of measurement. The OGC GML 3.2.1 specification defines its value under section 8.2.3.6. It can be either a string, without any colons, spaces, tabs, carriage returns or line breaks, or a URL. When using strings, following the Unified Code for Units of Measure is recommended. For example, you could use m for meters, cm for centimeters, [ft_i] for feet (international definition) or [ft_us] for U.S. feets. It is highly likely that most systems will only support meters.

Examples

<!-- GeoRSS Simple -->
<georss:circle>-24.62759969859908 -70.40503541618583 14.74038882</georss:circle>
<georss:featureName>Antu, VLT-UT1</georss:featureName>
<georss:featureTypeTag>telescope</georss:featureTypeTag>
<georss:relationshipTag>has-nothing-to-do-with</georss:relationshipTag>
<georss:elev>2635</georss:elev>

<!-- GeoRSS GML -->
<georss:where>
  <gml:CircleByCenterPoint>
    <gml:pos>-24.62759969859908 -70.40503541618583</gml:pos>
    <gml:radius uom="m">14.74038882</gml:radius>
  </gml:CircleByCenterPoint>
</georss:where>
<georss:featureName>Antu, VLT-UT1</georss:featureName>
<georss:featureTypeTag>telescope</georss:featureTypeTag>
<georss:relationshipTag>has-nothing-to-do-with</georss:relationshipTag>
<georss:elev>2635</georss:elev>

Notes

The GeoRSS documentation on ArcGIS Online mentions supports for circles on GeoRSS Simple, but excludes them from GeoRSS GML. I would therefore advise against trying to use a CircleByCenterPoint. It is likely that the few GeoRSS implementations out there will only support <georss:circle>, if they support circles at all.

The W3C Feed Validation Service does not support circles in either its GeoRSS Simple validator or its GeoRSS GML validator.

Circles were probably either added before <georss:radius> was introduced, or added, then partially removed when someone noticed <georss:radius> could already do the job. Another possibility is that circles and curves are far less supported by GIS software than linear geometries, so they wouldn't be that usable anyway. This raises interesting questions: what happens if you use a circle, but also add a radius around it? Do you get a larger circle? Is the radius ignored? Does it become an approximation of a circle as a polygon, as is common with GIS software that doesn't support circles? Those questions will definitely remain unanswered, as with most things about RSS, the answer of most organizations nowadays will be "who cares?". This is why we can't have nice things.

Coordinate systems

If I ask you to give me something that will precisely point at some place, any place in the world, including the middle of the ocean, you’re likely to give me so-called GPS coordinates. Those actually are WGS 84 coordinates. They represent a location on Earth, assuming the Earth is a perfect ellipsoid (a sphere, but slightly squished at the poles), whose center is the planet’s center of mass. But there are a lot of other ways to produce coordinates. Even now that GPS coordinates are ubiquitous, many other systems are still in use, for historic reasons, due to technological constraints, or for an increased precision.

Let’s start with a simple one. How do you represent coordinates in three dimensions? We did see earlier that GeoRSS has <georss:elev> to set the elevation in meters, but what if you are trying to represent a line that is sloped? For example, you are making your own Strava and want to show that you went up and down a hill. Your track won’t be perfectly at sea level, it will have an altitude that changes with each point. You need some way to include the altitude along with the latitude and longitude. In a geospatial database, the typical GPS coordinate system in use is numbered EPSG:4326; store this number next to your coordinates and the database knows you are speaking in WGS 84. But if you want to add a third coordinate for altitudes, you will have to use a different version of the system numbered EPSG:4979. It’s the same as GPS, but there’s a third axis for a height, starting from the ellipsoid defined by WGS 84, and measured in meters.

Going beyond Earth

Let’s go further. With all the hype around a bunch of space agencies trying to build a moon space station and two moon bases and sending rovers and all, we have to start thinking about an equivalent of GPS for other planets, and a way to refer to places on any planet. Fortunately, space agencies have had this problem a long time ago, and they have their solutions.

If you define your own geographic coordinate system, you can make your own ellipsoid to describe the shape of the planet, set the origin point (the 0° north 0° east point), and define how altitudes are expressed if you want to have a third dimension. On top of that, you can define a projection to flatten your planet, but that’s a whole another can of worms and I won’t deal with that here. You could define a coordinate system for the moon, with an ellipsoid that has the size and shape of the Moon, centered on the Moon’s center of mass, and define wherever you want your origin point to be. And you can do the same thing for basically anything, assuming you can somehow trick geospatial databases into bending a spheroid hard enough to fit your needs.

And that’s what the IAU did. Those are the same people who said Pluto isn’t a planet, so I don’t know if you can really trust them, but I haven’t seen any other coordinate system for other planets that was in widespread use within the space industry. There are lots of coordinate systems and projections for planets and moons, including some for Earth because we clearly needed more. For the Moon, you’ll have to use IAU2000:30100, aka Moon 2000. This doesn’t mean the Moon is Y2K-ready, it just means this was adopted by the IAU in 2000. Moon 2000 is defined in a geospatial database like so:

GEOGCS["Moon 2000",
    DATUM["D_Moon_2000",
        SPHEROID["Moon_2000_IAU_IAG", 1737400.0, 0.0]],
    PRIMEM["Greenwich", 0],
    UNIT["Decimal_Degree", 0.0174532925199433]]

The PRIMEM specifies the primary meridian, at 0°; it is called Greenwich even though it definitely doesn’t exist on the Moon, because nobody cares about its name. We also don’t specify anywhere what the actual location of the origin point is, because databases don’t care about that either. The UNIT specifies that we are using decimal degrees for coordinates, with the long number being the multiplier to convert degrees to radians. Those are almost always present in most coordinate systems.

What matters for the Moon is the SPHEROID, with its two parameters, the semi-major axis and the inverse flattening. A spheroid is just another name for an ellipsoid.

In a sphere, the semi-major axis is the radius. In an ellipsoid, that would be the largest radius, as opposed to the semi-minor axis. The inverse flattening defines how hard you should squish the sphere to get an ellipsoid, so it allows calculating the semi-minor axis. Here, we have 1737400 as the semi-major axis, which matches the radius of the Moon in meters, and 0 as the inverse flattening, meaning this is a perfect sphere.

Remember how I mentioned in a previous post that GML is designed to represent anything about geospatial data? You can check out the GML representation of Moon 2000 if you wish to be spooked.

From the Moon to WGS 84

So let’s say we have some Moon 2000 coordinates, for example Tranquility Base, at 0.6875°, 23.433333°. How do you put that into GeoRSS?

Since databases don’t care one bit whether what you are doing makes any sense, you could convert directly from Moon 2000 to WGS 84. That would make the database assume that your coordinates are just on a very weirdly-shaped Earth. Since coordinates are in degrees, the size of the Earth doesn’t matter, and the coordinates will remain unchanged after this conversion; maybe with some slight changes to account for the differently-shaped ellipsoid. You are now in some weird place in Democratic Republic of the Congo.

To do the proper conversion, you will need to do some trigonometry. Your Moon 2000 coordinates and the Moon 2000 spheroid are related to the center of mass of the Moon. WGS 84 is the same for Earth. Knowing the distance between the Earth and the Moon’s centers of masses, and knowing the position of the Moon on the Earth’s surface at a given date and time, it should be possible to get the offset in degrees to add to the latitude and longitude to said position to get the position of your target on Earth, as well as the altitude from Earth.

That’s a mess, and you can do something easier than that: just make it someone else’s problem. GeoRSS GML lets you set a different coordinate system using the srsName attribute. And if you are using any amount of dimensions other than two, you can use srsDimension as well.

Examples

Here is an example of one of the telescopes of the VLT, the same that I mentioned in my post about circles in GeoRSS, but using a third dimension in its coordinates instead of the <georss:elev> tag:

<georss:where>
  <gml:Point srsName="urn:ogc:def:crs:EPSG:9.0:4979" srsDimension="3">
    <gml:pos>-24.62759969859908 -70.40503541618583 2635</gml:pos>
  </gml:Point>
</georss:where>
<georss:featureName>Antu, VLT-UT1</georss:featureName>
<georss:featureTypeTag>telescope</georss:featureTypeTag>
<georss:relationshipTag>has-nothing-to-do-with</georss:relationshipTag>

To specify that I am using EPSG:4979, I am using the srsName attribute with a URN, specifically an OGC URN, which defined that def:crs: defines a coordinate reference system. EPSG says the authority defining this system is the EPSG, 9.0 is the version number of their Geodetic Parameter database, and 4979 is the identifier of the system within that database.

I am also using srsDimension, which allows specifying how many dimensions the coordinate system has. While this could be guessed from the coordinate system, this allows feed parsers and validators to know that they should expect coordinates of this amount of dimensions without having to know about coordinate systems, which can simplify implementations. Perhaps you can just send the srsName verbatim to some other software library specialized in coordinate systems.

And here is Tranquility Base! Since the IAU2000 coordinate systems and projections do not have a URN, I am instead using a URL to the GML definition of the coordinate system I want.

<georss:where>
  <gml:Point srsName="https://spatialreference.org/ref/iau2000/30100/gml/">
    <gml:pos>0.6875 23.433333</gml:pos>
  </gml:Point>
</georss:where>
<georss:featureName>Tranquility Base</georss:featureName>
<georss:featureTypeTag>landing-site</georss:featureTypeTag>
<georss:relationshipTag>used-as-example</georss:relationshipTag>

Reference

srsName

The spatial reference system used for this geometry. This should be either a URN for a common system, for example urn:ogc:def:crs:EPSG:<version>:<identifier>, where <version> is the version number of the EPSG database of spatial reference systems, and <identifier> is the number of the system. For EPSG:4979, you could use urn:ogc:def:crs:EPSG:9.0:4979. For an SRS that does not have a URN, or has a custom definition, you can use a URL that points to the definition of this SRS in GML. For IAU2000:30100, you could use https://spatialreference.org/ref/iau2000/30100/gml/.

The W3C Feed Validation Service allows this attribute, but does not perform any validation on its value.

srsDimension

The number of dimensions of this spatial reference system. Since the default is the 2-dimensional WGS 84 (EPSG:4326), you will always need to set srsName along with this. This is always implied by the system you are using, but this makes it easier to validate your data since a GeoRSS validator does not have to know how the SRS defined, or understand the concept of SRS, to be able to tell if you put the right amount of coordinates in your data.

You can set both of these attributes on <gml:Point>, <gml:LineString>, <gml:LinearRing>, <gml:Envelope>, <gml:Polygon> or <gml:CircleByCenterPoint>. You can also set these directly on <gml:pos> and <gml:posList>, but the XSD for the GeoRSS GML Application Profile says that "It is expected that this attribute will be specified at the direct position level only in rare cases".

While the W3C Feed Validation Service supports this attribute, it only validates that it is a valid positive integer, not that it matches the specified SRS, or that the coordinates specified in the geometries match this attribute. It also does not allow this attribute on <gml:pos> or <gml:posList>.

The NHC provides a myriad of feeds, with an RSS button available on the header of every webpage, but the list of feeds it links to is quite hard to read. Feed autodiscovery is supported, with 11 of their feeds listed as <link /> tags. Among this hodgepodge of feeds, you'll find:

• 2-day forecasts for every depression, storm or cyclone under their watch, as images or as text;
• Updates to their KMZ or SHP exports, either individually for each cyclone or for an overview over one of their three regions, for geospatial people, with further docs on how to use them;
• Descriptions of each depression, storm or cyclone as separate items;
• The latest weather report as a podcast (this seems to be inactive);
• Flight plans for any weather reconnaissance flights they might have each day;
• Discussions, longer weather reports written less to follow a standard maritime/aviation weather report and more to be human-readable;
• Monthly overviews of tropical weather;
• Forecasts dedicated to navigation in offshore waters, in high seas, HF radio transmission quality, probable wind speeds for storms, etc.;
• Advisories of incoming hurricanes, or forecasts, or status updates, or ICAO-compliant ones.

That's a lot. Most of these feeds are divided by region (Atlantic, Central Pacific or East Pacific, per WMO conventions), and by "storm wallet". A storm wallet is a large binder or collection of binders that forecasters used to archive all of their data into once each cyclone dissipates, numbered 1 to 5, to match the maximum advisory level reached. In the case of those feeds, this means each storm wallet is actually the current advisory level for the storm. Some feeds also have versions in Spanish, updated by their Puerto Rico office when they feel like it.

To make it slightly easier for feed aficionados (afeedcionados?) to figure out what they might be interested in, I wrote a terrible script to build an OPML file listing every available feed. You can access it and add it to your feed reader here; feel free to remove the likely numerous duplicates from your reader afterwards.

Note that some of these feeds include a <gml:Point> element in the items describing weather systems, but it isn't wrapped within a <georss:where> element, making those feeds invalid. This strangeness is what made me have a deeper look into GeoRSS in the first place, leading to the series of articles I posted in the last few weeks.

With the help of the NHC's example files, published solely to help developers work with their feeds, and GIS RSS feeds documentation page, I cobbled together an XSD to better document this namespace.

<rss
  version="2.0"
  xmlns:nhc="https://www.nhc.noaa.gov/"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="
    https://www.nhc.noaa.gov
    https://envs.net/~lucidiot/rsrsss/xsd/nhc.xsd
  "
>
  <channel>
    <!-- ... -->
    <item>
      <!-- ... -->
      <nhc:Cyclone>
        <nhc:center>38.43317, -82.02346</nhc:center>
        <nhc:type>TROPICAL STORM</nhc:type>
        <nhc:name>FLORIDA MAN</nhc:name>
        <nhc:wallet>EP3</nhc:wallet>
        <nhc:atcf>EP872023</nhc:atcf>
        <nhc:datetime>11:11 AM PDT Wed Jan 25</nhc:datetime>
        <nhc:movement>NE at 54 mph</nhc:movement>
        <nhc:pressure>984 mb</nhc:pressure>
        <nhc:wind>115 mph</nhc:wind>
        <nhc:headline>...FLORIDA MAN MESSES UP THE TOWN OF HURRICANE, WV...</nhc:headline>
      </nhc:Cyclone>
    </item>
  </channel>
</rss>

Note that in this example, I am using the xsi:schemaLocation attribute to tell any XML schema validators where the XSD for the nhc namespace is located. This can help you if you are using an XML editor to write your RSS feeds, or want some automatic validation of the validity of your feeds with namespaces and features that go beyond the W3C Feed Validation Service. Let's have a look at all those new XML elements:

<nhc:Cyclone>

A tropical weather system: a tropical depression, tropical storm, hurricane, etc. This can only be used on items, not channels, and can only be used once per item.

<nhc:center>

WGS84 coordinates of the center of the weather system, as latitude then longitude separated with a comma and optionally spaces.

<nhc:type>

Type of the weather system: whether it is a tropical depression, tropical storm, hurricane, etc. Usually written entirely in uppercase.

<nhc:name>

Name of the weather system. Usually written entirely in uppercase.

<nhc:wallet>

The storm wallet: Back before hurricane forecasting became computerized, all of the hurricane data was stored in binders, called wallets. There are five wallets for each of the three areas of responsibility of the NHC and the CPHC.

Storm wallets are numbered with two letters representing the area of responsibility, followed by a digit from 1 to 5 matching the storm advisory number. The two-letter codes for areas of responsibility are:

AT

Atlantic

CP

Central Pacific

EP

Eastern Pacific

<nhc:atcf>

Storm identifier in the ATCF software. This is the software used for hurricane forecasting ever since it became computerized. It can be used to find the raw data from that software on the NHC's public file server.

ATCF IDs begin with a two-letter code for the area of responsibility, followed by a two-digit storm number and the four-digit year in which the storm occurs. The two-letter codes for areas of responsibility are:

AL

Atlantic. Note that this is different from the AT code for storm wallets.

CP

Central Pacific

EP

Eastern Pacific

Storm numbers 01 to 30 are supposed to be unique storm numbers per season. Storm numbers 80 to 89 are used for training purposes and should be ignored when trying to process real ATCF data. Storm numbers 90 to 99 are areas of interest to forecasters that may not actually be storms and may be reused in the same season.

I recommend using storm numbers between 80 and 89 if you want to mess around and create fake storms, since those are explicitly designated as training or testing data that should be discarded. Also note that storm numbers 31 to 79 are not assigned, and that they assume there will never be more than 30 storms in one year. I'm sure climate change will fix that.

<nhc:datetime>

The date and time of the report, using the strftime format %I:%M %p %Z %a %b %d. The commonly used timezones are CDT on the Atlantic reports, PDT on Eastern Pacific reports, and HDT on Central Pacific reports.

<nhc:movement>

The direction and speed of movement of the storm, expressed as a cardinal direction and a speed, usually in the form [direction] at [speed] mph. The direction can be a cardinal (N, S, E, W), intercardinal (NE, SE, SW, etc.) or secondary intercardinal direction (WNW, ESE, etc.). Speeds are non-negative integers, and always in miles per hour.

Note that this is a manually written value, not necessarily intended for machine consumption, and that nothing prevents other values from being set. Other known values include Stationary and Nearly stationary.

<nhc:pressure>

The atmospheric pressure at the center of the storm, expressed in millibars without decimals, as [pressure] mb.

<nhc:wind>

The wind speed in the storm, expressed in miles per hour without decimals, as [speed] mph.

<nhc:headline>

A headline for the report, usually written in uppercase, with each sentence surrounded by ellipsis characters ("…", …, U+2026).

All of the child elements of <nhc:Cyclone> are required.

And as with most of the XML namespaces that I showcase on this feed, I added support for it on the XSLT that allows this feed to be displayed on most modern web browsers without RSS support. View this post in your browser and admire the additional hurricane information available!

In the middle of an IRC conversation, I mentioned how I was only reading the blog articles of my friends that I spot in my feedreader, right after mentioning I read 40 of brennen's posts. He proceeded to build an Atom feed with every single post from his website all the way to November of 2020, which is as of writing still available here. If you want to stress test your feedreader, or how much you like to read blog posts, add this feed. Don't expect it to be updated though since it was generated manually just once.

I went through every single of the 1960 entries of this special feed in just one month, and I read the other few dozen posts that were posted in the years since. It was really fun to follow along as ~brennen grows up. He told me he thought the older entries were embarrassing, and I can understand that since I also feel shame at things I put up online when I was younger, most of which I have deleted ever since. But going through all of his posts was fascinating. I wasn't laughing at young him or thinking any less of present him. I was just watching someone growing up a decade earlier than me, in a different country, with a different culture. I believe there is some great historical value in this online diary, just like how historians are studying the past by reading diaries. I hope ~brennen carries on with this great undertaking and continues shoving random tidbits of his life into this website. This is the World Wide Web at its finest: humans just being human.

I could not find it anymore, but a while ago, I read a blog post about someone watching someone else use a PSP to access GOV.UK on some free Wi-Fi to do whatever business you might have on your government's website. They used that as an example of how good Web design allows accessibility, even to people whose only device might have an incredibly limited browser and who still need to fill out governement forms online. My own experience with browsing the web on a PSP teaches me that accessing any website nowadays is extremely difficult, but I am willing to believe that blog post because GOV.UK's design sounds like it could actually fit on a PSP, or at least still be readable.

GOV.UK's design system causes the website to often be listed on lists of "brutalist websites", due to the design being all about clearly displaying what people are looking for, unlike what most heavily monetized blogs or most web apps do now.

But we're not here to talk about website design of course. Another interesting and much more relevant part of the UK governement website is that they have feeds, and a lot of them. Integrating the UK transport accident investigation branches into https://tilde.town/~lucidiot/itsb/ was trivial, just pick the right filters and get your tailored Atom feed. I have started to randomly stumble upon the feeds of other UK public bodies, and I think I'll have to soon spend more time trying to list all the feeds they have because there's a lot to discover. A lot of feeds, of XML namespaces, of relationships to European projects, and probably more.

Let's just start with this rather simple feed: you can get updates on the current national terrorist threat level set by the MI5. I was both surprised at the fact that that's a feed, a feed that only gets updated at most twice a year, and at the fact that they have a separate threat level set for Northern Ireland. I'm fairly sure having a separate Vigipirate level in France for Corsican independentists would just be a self-fulfilling prophecy, causing them to attack more.

I naively hope the UK someday stops all its political bullshit, but only so they can keep feeding me more feeds, and inspire other countries to do the same.

I like using RSS feeds as a means of getting not just blog posts. Getting warnings about delays or changes on a commute over RSS sounds really nice. Getting the kind of information that people think they need phone notifications for, or the kind of information companies want to you think you need a mobile app full of data collection for. And most importantly, getting it all into a system designed to handle a large amount of information, to sort it, to filter it, to display it conveniently, instead of just a sort of tray that doesn't fit more than a few notifications.

This reminds me of a BlackBerry Q5 I used before I switched to OnePlus. BlackBerry OS 10 is just Android with a BlackBerry UI, and its notification center was quite nice and could clearly better handle a large amount of notifications than Android or iOS' default interfaces. I guess this is just what happens when you design something to be used for more than just doomscrolling and swiping left or right on random faces.

Anyway, since I like to get all the interesting feeds neatly organized into even more XML, I wrote a script to generate an OPML file for all the Chicago Transit Authority feeds. Since they provide feeds for both a single line or category of alerts and for all at once, you'll get duplicates if you import that, but at least you will know about all the available feeds.

These feeds are quite strange. They use non-namespaced extensions to RSS, which are illegal but will not break most feedreaders, to give some metadata on each item:

<reference>

A unique identifier for the event. I suppose this could just have been a <guid isPermaLink="false">.

<road>

The number of the road where the event occurs, like M20.

<region>

The region where the event occurs, which is equivalent to the region names in the regional feeds list.

<county>

The county where the event occurs.

<latitude>

The WGS84 latitude of the event's location. This could have been a <georss:point> or a <gml:pos> or a <icbm:latitude> or a <geo:lat>…

<longitude>

The WGS84 longitude of the event's location. This could have been a <georss:point> or a <gml:pos> or a <icbm:longitude> or a <geo:long>…

<eventStart>

ISO 8601 date of when the event starts. This could have been a <ev:startdate> from the RSS 1.0 Event Module.

<eventEnd>

ISO 8601 date of when the event ends. This could have been a <ev:enddate> from the RSS 1.0 Event Module.

<overallStart>

ISO 8601 date of when the cause of the event starts. For incidents, this is the same as <eventStart>. For road works that start before the event occurs (for example, road works that only close a road during a given time of day), this will be a different date.

<overallEnd>

ISO 8601 date of when the cause of the event ends. For incidents, this is the same as <eventEnd>. For road works that end after the event occurs (for example, road works that only close a road during a given time of day), this will be a different date.

Obviously, not a single feed reader will support these tags.

A larger issue however is just the sheer amount of items. Adding this OPML into a feedreader made it pull over fourteen thousand items. Now of course there are a lot of duplicates, since there are feeds by road, area, and for the whole network, as well as for incidents, roadworks, or both at once. The everything-everywhere firehose still has three thousand items, with tons and tons of roadworks everywhere.

Just the incidents-everywhere feed gets a new item from every few minutes to every few seconds, which is the fastest update rate I have ever seen on a feed. I guess those feeds really can only be used by software for further processing.

The first OPML file that got generated automatically was for the feeds of the National Hurricane Center. It initially used a shell script that combined some JavaScript code via Node.js and a call to oq, a wrapper around jq that can convert between YAML, JSON and XML.

The JavaScript code was retrieving the NHC's RSS feeds list page and parsing it using a regular expression. It would then generate a JSON representation of an OPML file, which gets converted to XML almost as described in this nearly 14 years old article by oq. That's how I was used to generating feeds within my ITSB project.

But that did not mean I was really happy with this. I do not like having a lot of dependencies in my projects, particularly those that can be heavy or restrictive in terms of CPU architectures. Ideally, I would like to be able to do almost everything on Windows XP, since one of my many other niche interests is in older Windows systems.

XProc and XQuery

While going through the XML-based standards category on Wikipedia to look for potentially interesting namespaces for RSS feeds, I stumbled upon XProc. XProc is an XML schema that lets you define pipelines, particularly to process XML data. This reminded me of the main XML file of ITSB, which holds both the contents of its homepage and the instructions to generate the hundreds of feeds it serves. A series of XSLT turned that file into either the HTML homepage, an OPML containing all the feeds, or a Bash script that can be executed to generate all of the feeds.

XProc looked like an interesting path to rewrite ITSB entirely and make it go beyond only generating feeds for transport accident investigation reports, which is something I have been thinking about for a while. However, the only mature implementations of XProc appear to be in Java, which is a hard no in most of my projects. Searching for xproc on GitHub made me find xproc.xq, an XProc implementation that relied on a Java implementation of another strange language, XQuery.

XQuery, the XML Query Language, is an extension of XPath, a language that you probably encountered if you have been working with XML for a while. XPath is used within XSLT, and it's often one of the quickest ways to extract something from an XML document with most XML libraries if you don't want to deal with the complexity of converting between the XML paradigm and your programming language's. You can even use it within your browser, with the Document.evaluate() method of the DOM API.

While XPath is mostly meant to give a succint way to describe a filter on XML data, XQuery goes beyond that and allows iterating on and processing that XML. You can probably rewrite any XSLT into an XQuery script, and it will probably be easier to read. XQuery allows declaring functions, using variables, etc. and even provides a syntax that reminds me of SQL and SPARQL:

for $galaxy in //galaxy, $planet in .//planet
group by $galaxy, $type as xs:string := $planet/@type
where count($planet) > 3
group by $type
let $count := count($galaxy)
stable order by $count descending
count $i
return <type id="{$i}" name="{$type}" count="{$count}" />

This example, in an imaginary XML document holding the universe, computes how many galaxies have at least three planets of a given type, then returns those planet types, starting with the type with the most galaxies, and including a unique identifier. The ordering is marked as stable, forcing the XQuery implementation to order any types that have the same count in the same order on every execution. This is a quite complicated expression, but you can do way worse in XQuery. This would probably be doable with an XSLT, but it would definitely be very painful.

The XProc implementation I found in XQuery was using some MarkLogic Server extensions. It is a document-oriented database that lets you run either XQuery or JavaScript to query its data, and it is proprietary, so I was definitely not interested in trying to use it. A fun thing to note however is it that it also provided unit tests via xray. You know you've got a strong query language when you can have a unit testing framework for it!

I went looking for an open-source XQuery implementation that does not require Java, and that could provide enough vendor-specific extensions to replace those used within xproc.xq. I first found Zorba, basically MarkLogic Server but open-source, and it provided an impressive amount of extensions. You can even interact with SQLite databases in it, to use a query language within a query language. Unfortunately, Zorba is an incredible mess to build, so I quickly gave up trying to package it for Alpine Linux and tried to find something else.

Xidel

I gave up for a little while, then stumbled upon Xidel, an open-source tool written in Pascal that supports applying CSS selectors, XPath queries, XQuery scripts, as well as JSONiq, a JSON equivalent of XPath and XQuery that got merged into XPath and XQuery 3.1. It can make HTTP requests, parse HTML (not just XHTML), submit HTML forms found in pages, interact with the filesystem, run other processes, and more.

It could allow me to merge every single of the tools that I use in ITSB into just one dependency. And that dependency is just one statically compiled executable that I can easily download automatically in scripts if I need it. And Pascal can be compiled on a lot of platforms. Xidel does work on Windows XP!

I started playing around with it, and very quickly decided to rewrite my NHC OPML generator with it to drop the Node.js, oq and jq dependencies. That is how I ended up with the current implementation of the NHC generator.

I then rewrote the CSS sprites generator. I use a single image for all of the icons displayed in the web version of RSRSSS, and some CSS to take just a portion of the image each time to get one icon at a time. I also took the time to optimize the CSS.

That sent me on a roll, and I started writing a whole bunch of XQuery scripts, including one to use the W3C Feed Validation Service from the command line, and started looking for websites that would give me good OPML files to make.

That's how there has been a wave of OPML files coming in recently. I just want more excuses to write in XQuery! If I find the motivation to work on ITSB again, I will definitely be introducing Xidel in it and start slowly converting everything to it. I have also considered using it as a static site generator, and for a few other projects.

In some email exchanges, I have dubbed Xidel the Overwhelmingly Powerful Mother Of All Legendary XML/HTML/JSON Processor of Doom due to how impressed I was with how versatile it, and XQuery, are.

So, if you find yourself trying to extract data from HTML, XML or JSON documents, do check out Xidel. It might not be as trendy as other tools like jq, but it is a lot more powerful.

Desktoptwo was emulating some mix of the Windows, Mac and Linux desktop experiences, in a web browser. You had a few simple apps available like a notepad, and some storage space to keep your files on their servers. You could also use OpenOffice Writer, Calc and Impress: those would open a remote desktop connection within the browser to the actual OpenOffice running on their servers. It was quite impressive for the time.

At a similar time, I had also played with the Microsoft Office 2007 "Test Drive", powered by Runaware. Using Internet Explorer only, you could for a short amount of time play around with Office 2007 on a Windows XP virtual machine, using Citrix. Runaware also had other demos running, including one for Sage. I remember spending a lot of time just messing with those virtual machines, without knowing anything about the technology that made this possible yet. I was like 10 years old!

A few years later, I had found eyeOS, yet another WebOS, but that you could self-host this time. It had more applications available, but they were less interesting—the whole thing was more meant to be a demo of what apps you could create with it. They had something akin to an app store. I tried both their own demo instance and hosted my own, as I had learnt a bit more about webservers by that time.

I now tend to be wary of large piles of JavaScript like those as the current state of the JavaScript ecosystem tends to make everything worse, so I don't generally care much about the current attempts at making a new WebOS, like OS.js… unless they are fun.

Windows 93 is a pretty well done recreation of the Windows 95 user interface that started in 2014. It has a community that provided plenty of new apps to give the system a lot of content and fill it with weird jokes and "viruses". This is definitely not meant to be a replacement for a desktop OS like Desktoptwo or eyeOS attempted, and just a weird bundle of apps and games that mix the modern web and 30-year-old designs.

Their RSS feed gives some rare status updates about the project. I thought the project had been pretty much dead by now, since the feed had gotten no updates at all in a long while, but they announced that they are working on a full rewrite. Version 3 will be open source, and it will be based on Sys42, their own custom framework that skips one of the worst parts of modern JavaScript (Webpack) and allows building any web OS, not just a whimsy Windows 95 clone.

I am impressed by how much effort people sometimes put into these projects.

• Have one, and only one, <h1> tag. That will be your feed's title.
• Have each blog post surrounded in <article></article> tags.
• Have each blog post start with an <h2> tag, whose contents should start with an ISO 8601 date: 2023-02-31 Climbing the Reichstag dressed as Spider-Man. The date will be the Atom entry's date, and the rest will be the post's title.
• Have literally anything else within that article; that will be the post's content.

If you like a verbose specification, well there's one. But the list above is the gist of it really.

Once you've got your page available somewhere online, you can use https://journal.miso.town/atom?url= followed by your page's URL to get a feed. Or you can use this form if you can't be bothered with URL-encoding the URL, which is definitely understandable. You can also use a validator.

There are plenty of HTML-to-RSS tools, including some that use CSS selectors, let you do custom scripting, or are tailored to one specific platform like Twitter. But I really like the simplicity of HTML Journal: Just structure the page in the spirit that HTML5 intends, and suddenly, you've got a feed.

This is the 100th post on RSRSSS, and it recently became three years old. Thanks for following along, and I'll see you next year!

• Have one, and only one, <h1> tag. That will be your feed's title.
• Have an unordered list (<ul>) to list all your pages.
• In each list item (<li>), have a <time> tag to specify the ISO 8601 date of the post. That will be the Atom entry's date.
• In each list item, have a <a> tag. The href should point to the page of your post, and the link's contents will be the post's title.

Just like with HTML Journal, there is a longer specification for this.

And just like with HTML Journal, you can use https://blog.miso.town/atom?url= followed by the blog's URL, or use this form, and you get a validator.

But here's an argument that I don't remember ever seeing in this constant bickering: the fact that there are technologies out there that rely on feeds. Moving those away from feeds would be very costly. Here are a few use cases that I found while going down different rabbit holes.

Podcasts

Podcasts are still very much popular. While most people nowadays will be listening to podcasts through some streaming services like Spotify, iTunes, or podcast-specific platforms, podcasts started out just as <enclosure> tags within RSS feeds, and that's how those platforms fetch them.

Spotify imports podcasts from RSS feeds and have a specification for how they parse them. They also provide a feed if you are hosting your podcast on Spotify directly, so that you can share it elsewhere. All podcast hosting platforms provide feeds.

iTunes relies on feeds. They have their own XML namespace, which is likely to be found on pretty much every podcast feed as that became a de facto standard namespace for podcasts before the podcast namespace showed up.

Google Podcasts feeds on feeds, and also allows subscribing to an RSS feed directly without it having to be submitted to Google.

News

Obviously, a large amount of feeds are dedicated to news. Every single news website out there has an RSS or Atom feed hidden somewhere. Most of them will be sharing a link to it, either with an RSS icon somewhere on the page or with RSS Autodiscovery, but even if they don't, they still do have a feed. They have to have a feed in order to survive.

How can I say that so confidently? Well, because Google News feeds on feeds, Microsoft Start and MSN.com feed on feeds, Google Assistant feeds on feeds, Flipboard feeds on feeds, and just about any other news aggregator uses feeds.

It's the standard way to aggregate news articles, and a lot of people will start with a news aggregator to get their news, particularly Google News. It has so much weight on how news are accessed from that setting news.google.com as your referrer on HTTP requests can unlock paywalls and that various laws have been drafted to make Google News pay news publishers.

Ads

Google has leaned rather heavily on RSS, including for ads. For example, I randomly found this sample feed for an ad tech called Dynamic Ad Insertion, which sounds like it is how soulless people marketers can insert ads into livestreams and VOD. Google Shopping also feeds on feeds. Those feeds can be really detailed because of Google Base, yet another product they killed. Google Docs supports feeds. They probably are in other places, but since Google's ads are incredibly obfuscated, I don't even want to try and dig deeper into their unhelpful help to find more examples.

Google Base's legacy is also found at other companies: Facebook lets advertisers send them a list of products as RSS and Atom feeds with Google Base attributes.

GIS

Real-time information that includes geolocations can be quite important, both in the public and private sectors. Waze for Cities exports data as GeoRSS. A lot of GIS software will support GeoRSS imports. And the GML and KML formats supports automatic updates. KML, the format behind Google Earth's data, is supported by the W3C Feed Validation Service for a reason.

Overcomplicated enterprise apps

Probably the only reason why the .NET Framework has a feed parser is because of feed support in WCF. WCF aims to represent business processes that mix a whole bunch of other apps together, like how hiring someone will require HR approval on some particular app, then payroll needs to be notified, security issues a badge, etc. You draw the diagrams of the processes in Visual Studio, implement every step as a bunch of .NET code that probably calls out to other apps, and then have a WCF server somewhere to handle that stuff.

IBM has an equivalent support in Business Automation Workflow.

Oracle HCM provides Atom feeds so that other apps can be notified of changes on more HR stuff.

Corporate applications are probably among the slowest-moving software out there, so it's very unlikely that those will drop their support for feeds any time soon.

TL;DR: Money

Those few examples are far from an exhaustive list and they just show some of the things I have stumbled upon, but they are enough to prove that behind RSS and Atom feeds, there is money. And if a technology has been made necessary to make a profit somewhere, then changing it will be too risky and maintaining it becomes essential to capitalists. Even if the general public completely stops using feeds, they will still be out there somewhere, and thus tools, software libraries will still be out there to support them, and nothing will stop anyone from still using feeds.

I wanted to find a transportation themed feed to post here due to the weird occasion. I found the Houston TranStar RSS feeds, for information about the various highways around Houston. I made yet another OPML file to list all of those feeds if you feel like adding them all.

So I can now say that I have walked onto a highway to write an XQuery script, while watching a cyclist pass by while shouting "The road is ours! The world belongs to us!" This is a very… interesting day.

I particularly like the URL of this namespace.

<feed
  xmlns="http://www.w3.org/2005/Atom"
  xmlns:at="http://purl.org/atompub/tombstones/1.0"
>
  <at:deleted-entry
    ref="tag:example.org,2032:/entries/1"
    when="2032-09-11T12:46:00Z"
  />

  <at:deleted-entry
    ref="tag:example.org,2032:/entries/2"
    when="2032-09-11T13:03:00Z"
  >
    <at:by>
      <name>Chuck Norris</name>
      <email>chucknorris@example.org</email>
    </at:by>
    <at:comment>Chuck Norris did not like this post.</at:comment>
  </at:deleted-entry>
</feed>

The specification includes various considerations on ensuring that the entry was indeed deleted by the feed's authors and not someone else, as well as supporting the aggregation of deleted entries from multiple feeds into one. It is also possible to have a separate XML file that only contains the <deleted-entry> tag, which would have a MIME type of application/atomdeleted+xml, with an extension of .atomdeleted. Do check out the RFC if you want to learn more.

Of course, this is totally unreliable, since any reader that does not support this namespace will ignore it completely, and some potentially evil readers might even highlight the entry as needing to become another example of the Streisand effect. But in some applications, such as automated processing of Atom feeds for synchronizing some data, knowing for sure that something has been removed can be useful.

I searched for code that was referencing this namespace and found that a few YouTube Atom feed parsers do handle deleted-entry elements, so it might be possible that YouTube uses those tags. See here and here.

Nothing stops you from adding <at:deleted-entry> elements to RSS feeds as well, just like how other Atom extensions can already be used there. But most feed readers will skip over this namespace in Atom feeds, so it is likely that almost nobody will support this on RSS feeds.

And if you were expecting actual tombstones from this namespace, well do know that RSS feeds for obituaries are a thing. You're welcome.

I recently discovered that it has RSS 2.0 and Atom support, to let you monitor for emails received at your trash address. To activate this, you need to use an address on a domain that supports locking addresses with a password. Those domains are marked with the (PW) suffix on the homepage. Pick an address that is unlikely to have already been used, and you can then set a password on the web UI. The password is removed after 3 months of inactivity.

Once you have a password, you can access the RSS and Atom feeds using the following URLs:

• https://tempr.email/en/rss/[email address]:[MD5 hash of your password]
• https://tempr.email/en/atom/[email address]:[MD5 hash of your password]

For example, if your address is nope@gmai.com and your password is hunter2, then your feeds will be the following:

• https://tempr.email/en/rss/nope@gmai.com:2ab96390c7dbe3439de74d0c9b0b1767
• https://tempr.email/en/atom/nope@gmai.com:2ab96390c7dbe3439de74d0c9b0b1767

Note that if you are trying to use md5sum to compute the MD5 hash, do not forget to use print or printf, not echo, because echo will add a line break character that will also be hashed.

# Wrong hash!
$ echo hunter2 | md5sum
6a0f0731d84afa4082031e3a72354991  -

# Correct hash
$ printf hunter2 | md5sum
2ab96390c7dbe3439de74d0c9b0b1767  -

That's neat. I like the idea of emails to RSS feeds, since it lets you centralize even more things into your feedreader. There are obvious security concerns here with the automatic password removal, or the fact that MD5 hashes are used, which could imply passwords are stored as MD5 hashes, or worse, a plain text offender status. But it doesn't sound like it would be that difficult to secure your feed a little harder and get any email inbox as an RSS feed.

The comic updates less regularly now, but it is not dead at all, and the occasional comic showing up in my feedreader never fails to make me laugh at least a little. A nice addition to a large pile of feeds if you want a break from reading news articles from time to time.

That laptop was running Windows XP Pro. My cousins knew about the trick where you can reboot into Safe Mode and get access to a usually passwordless Administrator account, but they were only used to the Home Edition login screen where you can just click into the account, not to the Pro login screen where you have to type the username and password. I tried typing in Administrator without a password, and did get into the laptop, so we could play games on that laptop during our holidays.

I brought that laptop to a skate park and drew a scooter on Paint, then put it into an RTF document next to a cookie recipe, making this the oldest document that I created and still have in my archives.

A few months later, I stumbled upon Sweet Home 3D again, during a time where I was playing the Sims 2 and 3 with a classmate, and played with it and other 3D software to design random homes. I say design homes, but really I was just creating a new plan, drawing a house, and giving up halfway through or just making Sweet Home 3D render complete nonsense. I think more houses should have all of their furniture upside down, that sounds much more practical.

Anyway, I still do occasionally play with it nowadays. I found out that it was made by a French developer, and that the French forensics service got them to add more models, so you can now put shotguns in your houses! And most importantly of course, it has a blog with an RSS feed and an Atom feed.

Unfortunately, those feeds are annoying to deal with for machines. If you want to tell anything about the service's status somewhere else, scraping data from the feeds will be just as annoying, if not more, than the HTML document. We can do better though, and we have been able to do better for over twenty years.

The RDF Site Summary 1.0 Service Status module is one of many forgotten extensions to RSS 1.0. In an incredible plot twist you could never expect from its name, it is meant to report on a service's status, and provides some extra XML elements to help with that.

<rss
  version="2.0"
  xmlns:ss="http://purl.org/rss/1.0/modules/servicestatus/"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="
    http://purl.org/rss/1.0/modules/servicestatus/
    https://envs.net/~lucidiot/rsrsss/xsd/servicestatus.xsd
  "
>
  <channel>
    <!-- ... -->
    <ss:aboutStats>https://envs.net/~lucidiot/rsrsss/feed.xml#servicestatus</ss:aboutStats>

    <item>
      <!-- ... -->
      <ss:responding>true</ss:responding>
      <ss:lastChecked>1970-01-01T00:00:00+00:00</ss:lastChecked>
      <ss:lastSeen>1970-01-01T00:00:00+00:00</ss:lastSeen>
      <ss:availability>100</ss:availability>
      <ss:averageResponseTime>0.5</ss:availableResponseTime>
      <ss:statusMessage>Everything is fine.</ss:statusMessage>
    </item>
  </channel>
</rss>

Using those extra elements, you can report in a more machine-readable format on how your service is doing. Every element in this namespace is optional, and you can use them to report on whether your service is working, when that was last checked, when the server last worked, how well it is working, how fast it is working, and leave a message for human consumption, usually to report about how you are doing on fixing a specific issue.

The above example uses the xsi:schemaLocation attribute to point XSD validators to the schema I wrote to validate this namespace, if you want to validate your feed very hard. The W3C Feed Validation Service is aware of the existence of this namespace, so it won't warn about an unknown namespace, but it does not do any validation on its elements, so you'll need that schema to do any interesting validation.

The overengineered XSLT used to display this feed in HTML in modern browsers has been updated and supports this namespace, so you could use it directly to roll a status page that is nothing but an RSS feed, if you don't want to duplicate information. You can open this post in a compatible browser to get a preview.

Reference

<ss:aboutStats>

An RDF resource that should describe how the availability and averageResponseTime statistics are calculated in this feed. This should be used only on a channel element.

Note that anything is an RDF resource, and there are many ways to serialize an RDF resource as XML. However, the official specification only uses the form where the element just contains a URL, therefore this form is recommended. Feed generator implementers that do not know about RDF and its XML representation are likely to only use this form, and feed parser implementers are likely to only support this form.

<ss:responding>

Whether or not the service is responding.

<ss:lastChecked>

The most recent time a check was performed, as a W3C datetime, a subset of ISO 8601. You may want to have both the usual <pubDate> element and this element to share the same values. When the responding element is set to true, this should be exactly equal to lastSeen, meaning that this should be the end time of the last check, not the start time. If this was the start time, then lastSeen would be the end time, and they would not be equal.

<ss:lastSeen>

The most recent time a check was successful, as a W3C datetime, a subset of ISO 8601. When the responding element is set to true, this should be exactly equal to lastChecked. When it is false, the difference between lastSeen and lastChecked should give an estimate of how long the service was down for.

<ss:availability>

An integer representing the percentage of availability, between 0 and 100. How this availability is calculated is left up to the implementer and should be described by the aboutStats element.

<ss:averageResponseTime>

A decimal number representing the average response time of the service in seconds. How this availability is calculated is left up to the implementer and should be described by the aboutStats element.

<ss:statusMessage>

A message intended for human consumption giving further details about the service's status. This could for example warn of a planned outage, or give updates on how an ongoing issue is being worked on.

• AirNow-Tech is the platform where air quality data is sent, and where it can also be extracted, analyzed, used by partners (not just local partners).
• AirNow API provides APIs, data exports, etc. from AirNow-Tech. It requires a registration like AirNow-Tech, but this time anyone can register and get approved. The data exports are Atom feeds, but I am not including them since they are hidden behind that registration wall. To me, open data is not open if you have to register!
• EnviroFlash provides e-mail notifications for current air quality conditions, forecasts, and warnings to the general public. They also serve RSS feeds, as well as Atom feeds including CAP messages.

Since EnviroFlash is the only truly open website of the list, this will be the one I am featuring here. The feeds page provides an Atom feed that aggregates all of the CAP messages nationwide, and lets you select a state. Selecting a state and submitting the form triggers a script that uses AJAX to display a table of all the feeds available for that state.

Some states, like Alaska, have zero cities listed; in total, only 44 states have some feeds available. Each feed is specific to a city, and there are five different feeds for each city:

• The forecasted air quality for today and tomorrow, as an RSS feed;
• Health advisories, also known as "action days", as an RSS feed;
• The latest air quality information for the area, as an RSS feed;
• The current air quality alert, as a single CAP alert;
• An Atom feed for the current air quality alert, with either a placeholder entry when there are no alerts, or an entry holding a CAP alert just like the above one.

I wrote an XQuery script that lists all of the RSS and Atom feeds as well as the CAP alerts for all cities in all states, resulting in more than 3000 links, in one OPML file. If you need to do some load testing on your feedreader, now you know what to use!

EnviroFlash has made me discover CAP, the Common Alerting Protocol, a standard that I will look into in more detail in the future and that is designed to make emergency alerts more interoperable. I have already started to look into other sources of CAP alerts to learn by example.

Did you know that you can send FTP commands by e-mail to the NOAA's Ocean Prediction Center to retrieve their data? You'll get an email back with whatever your FTP commands resulted in. There are other similar e-mail based services, because e-mail happens to be quite resilient and lightweight, so it's a great thing to send over satellite. Here's a text file describing a few services, including the OPC's own.

Another of those cool services is the National Data Buoy Center, or NDBC for short. There are over a thousand buoys all over the oceans, both near the coasts and really far away from them, that send back weather or tsunami reports to various agencies, and the NDBC aggregates data from its own buoys and those of its international partners, as well as reports sent by ships. It provides the reports in various formats; text files, JSON, KML, etc., but most importantly of course, RSS.

I slapped some XQuery onto those RSS feeds to create yet another excessively large OPML file with over eight hundred feeds. You can get one feed for each buoy, but I found a way to get a feed of every observation at once.

From any station's page, you can find a link to all the observations in the area, either as a webpage or an RSS feed.

I found that the RSS feed version lets you change the default radius of 100 nautical miles to any other value using the &radius= URL parameter followed by a number of miles. The maximum range is 10820 nautical miles, corresponding to half of the Earth's circumference. Since this is a radius, this means you can indeed select everything!

Also note that this magical everything feed includes observations from ships, not just buoys, just so you can some extra spam.

I don't know that much about the maritime industry, but from my understanding from reading accident reports and other weird technical documents, large ships pay to get weather reports tailed to their needs from private companies, and smol ships rely on the weather information of the local coast guard, broadcasted regularly over radio. I don't know if any of those feeds are used by anyone, or what they would be used for, but boy am I glad that that's a thing! There is something really cool about getting RSS items that come from random chunks of metal floating around the oceans.

I plan on triple-booting Windows XP, Windows 7 and Alpine Linux on that thing. Windows XP would be the main OS, Windows 7 is there to support XP by giving me access to more modern tools including Ghidra, and Alpine is there to support both of those by being actually up-to-date and far less bloated. Since I name all of my Windows systems after industrial disasters, I will be naming this one AZF, in reference to an explosion at the AZF factory in France, on September 21, 2001.

While waiting for this new netbook to arrive, I am playing with my three Windows virtual machines, sometimes simultaneously as my main Linux computer could probably handle 20 of them. That makes me go through the various Microsoft documentations quite often, as well as of course the Internet Archive. While getting lost in a maze of broken links recovered through the Wayback Machine, I found a big Subscribe to RSS Feeds button on the Microsoft Support website, and lo and behold, feeds!

They provide both RSS 2.0 and Atom feeds for every product available on their support website. The <select> control that lists those products includes some interesting products such as DO_NOT_USE_Office Online Server. The feeds are available for each language of the website. With 80 languages, 2 feed formats and 204 products, we get 32640 feeds!

You can thus try to import the Microsoft Support feeds OPML file, the largest OPML file I have ever produced. Over five megabytes of feeds! You can probably use that for some really good load testing of your feedreader.

Transit Maps is a blog about… transit maps. The author publishes reviews of official maps past and present, and also offers constructive criticism of unofficial maps that people send to her.

Getting a new review in my feed reader gives me this sense of awe, this realization that some mundane things that we often take for granted require so much careful thought. You just walk to a map at the station, look at where you are and where you want to go, find your route and move on, and designers are spending countless hours making sure you can do that in a matter of seconds.

That reminds me of how poorly designed all software must be, simply because so many times, nobody stopped to just think about design. Maybe someday, software will be good, but I don't expect to see that in my lifetime. I will just keep on admiring transit maps instead…

Here comes NirSoft, a website by Nir Sofer providing nearly three hundred utilities to retrieve passwords, inspect browser data, monitor networks, manage installed programs, and more. Most of those tools still work on Windows 2000, which means they cover everything but one of the Windows OSes I am interested into, yet keep on being updated to include new features for Windows 10 or 11. You don't need the most modern frameworks to make good software after all.

The NirBlog is where you will mostly find announcements of major releases and features of those utilities. I find it always interesting to read the release notes of this kind of good software, because you will end up discovering more features that you would have never thought of using before.

Note that encouraging people to code does not necessarily mean that all programming should look like it is easy, especially bad programming. If software bugs can make planes crash, I don't want my grandma to make an autopilot. I just want people to automate tasks that they should never have to do manually.

Encouraging people to code also means encouraging them to code properly. You can and absolutely should write some very dirty script if it's some one-time use thing that you are going to throw away, but you shouldn't be doing this with a larger project, or with anything that will have to be maintained in any way.

I'm not the only one to think that way fortunately, and Rubberduck is a tool that tries to help in making sure users code properly. It is an add-on to the Visual Basic Editor, the tool built into Microsoft Office so you can write VBA code. Now, if I mention VBA, IT professionals will be terrified. That's understandable. But VBA is not going to go away from Office for a while, and it is still quite useful to really do anything with Excel or Access, and Excel is certainly not going to stop being the one tool that runs every organization.

When some users start to get really proficient with Excel, they might start implementing a little bit of VBA, just to do something that would have been impossible, or much harder to do, with just cell formulae. Then over time, their macros grow, they might even have custom forms on top, and you get an entire app based on Excel that is written like a script instead of being properly organized as an app. It becomes unmaintainable.

You will inevitably find something like this in any large organization. This is why VBA is often seen as a nightmare. Thus, IT people will try to discourage using VBA, and any kind of programming in general. This ban has a consequence, and it is similar to banning drugs: people will still be doing VBA or drugs, or VBA on drugs, but secretly, and you can't regulate its use anymore because you banned it entirely.

Rubberduck tries to help with this by legalizing VBA and regulating it. It is a static analyzer for VBE, offering many recommendations to avoid the various pitfalls of the language and make the code more readable, and adding plenty of features to make the IDE more modern. It's the equivalent for VBA of all the fancy tools that developers love to use nowadays, like type checkers, linters, etc. It's what happens when you embrace a programming environment, and treat it as equal to any other programming environment.

You don't even necessarily need to actively encourage users to code in VBA. You can just allow VBA under the conditions that they use Rubberduck, they take on the responsibility to maintain the project, etc., and you can get the situation a bit more under control. This lets power users do what they want. Those who would really benefit so much from some programming that they would be willing to spend a little time doing it as a side job. Those where management, especially American management of course, would never accept to let a professional developer work on it, even though it would make some lives easier. And with some help, it can avoid making the lives of professional developers harder in the future.

Congratulations to drugs VBA for winning the war on drugs VBA.

For a few years now, I have subscribed to the Earthquake Notification Service, a part of the USGS Earthquake Hazards Program. This service allows you to receive emails when an earthquake happens in specific areas, at specific times, of some minimum magnitude. You won't be notified instantly of course; I usually get emails a few hours later, after the seismic data has been analyzed and a new distinct earthquake was properly detected.

The ENS notified me that an earthquake occurred in France. It made the news and has a French Wikipedia page, as it was an unusual earthquake. Its magnitude would normally not be of much concern, but it damaged hundreds of homes and hurt 4 people. It also occurred in an area with a usually low, but not absent, seismic activity and high nuclear and industrial risks. It was suggested that the fault was on the brink of rupture, but that a quarry located just above the fault may have triggered it. Human activity as a risk factor for earthquakes is not that much taken into account in evaluating seismic risks yet, so it is likely that this area was riskier than we thought.

In my city, most people would not have felt anything because we are far away enough for this earthquake to be barely noticeable. There might be a small shake, but you wouldn't remember it or treat it as anything abnormal. As I was a few floors up in a building and in my bed, the vibrations got amplified enough for me to actually detect them, and I can now say that I felt an earthquake. Neat! If I had a bucket list, experiencing an earthquake might have been part of it.

Anyway, the USGS does not only provide emails for earthquakes. You can also get feeds! I wrote a generator to make an OPML file for the available Atom and KML feeds.

Those feeds are worldwide, but you can also use an API to make your own feeds with time, magnitude or location filters.

De Programmatica Ipsum is a magazine in the form of a blog. Every month, expect four new posts in your feedreader:

• An introductory post for the latest issue;
• An editorial post on the theme discussed in this issue;
• A book review;
• A video review.

The editorial post is often full of links to many resources, both historical and current, that can be helpful if you want to explore the theme deeper. I like that with the combination of blog posts, hyperlinks, books and videos, you get a variety of flavours on each topic.

Many issues explore hot topics or recurring issues in the industry, or interesting aspects of programming history. The editorial post of courses expresses many opinions, meaning that it will inevitably be very controversial because every opinion is controversial to the eyes of Hacker News. I however appreciate the more pragmatic approach here. It's more than just pure non-constructive criticism on a specific recent case with no research, it is a deeper dive into the repetitive patterns on most of the problems with software, over a span of decades. I can clearly sense that the writers are older, more experienced developers, some who might have been there before the advent of the World Wide Web.

This is a case of a tech blog where the author takes the time to think things through. That blog definitely stays in my feedreader.

I suppose that this feed must have been put into place at a time when RSS feeds were still cool, or encouraged in some way, and because this is a government website, they maintain it rather than enshittifying it into a newsletter like what companies would do. This might be another argument against privatization: more feeds!

Pedro Gil Farias, a design researcher, apparently did. On Are.na, basically fancy Pinterest, Pedro created Satellite Writers, a collection of graffiti seen on Google Earth, and thus captured by satellites.

This might anger you even more due to either of the aforementioned common thoughts on graffiti, or this might make you think a bit more deeply about how graffiti are just part of what makes a city a city. Either way, I now have a new niche photo feed in my reader!

So here is an OPML file for all of the SPC's feeds. Those feeds are pretty simple and rather well built. No GeoRSS, no custom XML namespace to describe tornadoes or storms. There isn't much to say here really! They provide lengthy explanations of the current weather reports for storms, as well as tornado or fire risks from those storms. The various feeds allow to select only some of their reports, for example tornadoes only.

So here is a new homemade OPML file, with nearly 2500 feeds grouped by state, providing the current weather conditions observed at American airports. They also provide a homegrown XML format, which you can get if you replace .rss any of the feed URLs in my file with .xml. This format is similar to the NHC's cyclones format, as it is only half-structured; the values are human-readable text instead of using basic machine-readable data types.

I already have a to-do list with a significant amount of NOAA feeds to look at, but I can't even make a dent in it, because I just keep on finding more. Don't take this wrong, I am definitely not complaining, as I would much rather have to deal with finding way too much RSS feeds everywhere than not finding any.

I live in a city with a network of over a dozen public libraries, and they are building another one soon. It's completely free for all residents, and there exists a loophole if you look very carefully to get a free card for non-residents. I am in the one library of this network that follows the Dewey Decimal Classification the closest, and has shelves that are quite well organized with many references to those numbers. Multiple libraries do not mention the numbers at all, leaving you to guess at what category a book you found online might be in. The fact that this library doesn't makes my experience much easier. I have been quite surprised today at how easily I found the books I am interested in.

The DDC continues to be updated regularly. They recently hosted a meeting to discuss the current classification of Ukrainian history for example. They have a TypePad blog that they have been maintaining for a long time. I have found this blog through a reference in some old publications about how RSS feeds could be useful to librarians, and it was the only one still active!

This feed is available in the Atom, RSS 1.0 and RSS 2.0 formats.

The K in KML stands for Keyhole, the company that got vored by Google and created what is now known as Google Earth. To be clear, by Google Earth I mean Google Earth Pro, the desktop version. The web Google Earth is really just a bloated version of the 3D view feature of Google Maps, which got removed to justify the existence of that separate web app. Google Earth Pro, which used to be a paid version of the free Google Earth desktop app, is now free and unmaintained. It still works fine though, probably because it's not fully written in JavaScript. It does work on Windows XP, although it sets my poor laptop on fire. Which is kinda fitting since that laptop is named //MORGUE/LUBRIZOL, after a fire that occurred in a Lubrizol factory in France.

Anyway, at first glance, Google Earth is not what I would call a feedreader, and KML files are not feeds either. However, my dear friend the W3C Feed Validation Service can validate it just like RSS and Atom feeds. Reading through the XML contents of the US feeds I found, and reading the specifications, shows that you can actually use a KML file as if it was an OPML file, listing a whole bunch of KML files as if they were feeds and specifying how often Google Earth should refresh them.

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
  <NetworkLink>
    <name>My KML feed</name>
    <visibility>0</visibility>
    <open>0</open>
    <description>Open this thing to view the contents of my feed with auto refresh</description>
    <refreshVisibility>0</refreshVisibility>
    <flyToView>0</flyToView>
    <Link>
      <href>https://example.com/feed.kml</href>
      <refreshMode>onInterval</refreshMode>
      <refreshInterval>60</refreshInterval>
    </Link>
  </NetworkLink>
</kml>

A NetworkLink is basically a folder that contains a separate KML file, loaded over the network. That file can be refreshed automatically in various ways, including whenever the user moves around in Google Earth. That option can be set to send the current camera settings, and that's intended for performance, so that you don't fetch any data from the other side of the Earth if the user can't see it. But that definitely can be used for tracking purposes, and probably is somewhere because we live in a great world. My example is configured to refresh the remote file automatically once every 60 seconds, without tracking you. You can also right-click on the link in Google Earth and hit the Refresh button to refresh manually at any time if you feel like it.

You can create those links within Google Earth with the Network Link option under the Add menu. The UI will however not allow you to configure everything, especially how or how not to send the view and camera parameters when moving around.

You can also put as many links as you want into a single file, place them into folders, or put network links in the remote file. That means you can fully reproduce the behaviors of OPML subscription lists, or even have a feed that is both a feed and a subscription list at once.

The linked KML file can be as simple as a single point:

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
  <NetworkLinkControl>
    <minRefreshPeriod>60</minRefreshPeriod>
  </NetworkLinkControl>
  <Placemark>
    <name>The Keyhole</name>
    <Point>
      <coordinates>37.4938932, -107.1192137</coordinates>
      <description><![CDATA[
        As seen on <a href="https://www.openstreetmap.org/node/358920287">OpenStreetMap</a>
      ]]></description>
    </Point>
  </Placemark>
</kml>

Note the NetworkLinkControl, which can be used to control how this file is meant to be used within a NetworkLink. This can give an additional layer of protection, since the properties of the original NetworkLink can be overridden by the server. The minRefreshPeriod ensures users can't just refresh the file every second, they have to wait at least one minute. This of course doesn't stop anyone from DoSing a server, but prevents them fro doing it over Google Earth.

Defining KML syndication

Here's a cool demonstration of the capabilities of network links in KML: download this KML file, and you can get Bing Maps, Yahoo Maps, or OpenStreetMap displayed within Google Earth. I think Google Earth is a great viewer, but I would like it to not depend on Google's servers, since we know what Google does with its products. That thing solves my problem! See also the OpenStreetMap wiki page on getting OSM in Google Earth.

That particular demo certainly would not fit the definition of a feed though. So here is a proposed definition of a KML feed:

• A KML feed is a KML file.
• A KML feed uses NetworkLink to link to another KML file on a server.
• A KML feed uses the onInterval or onExpire refresh modes, which will cause an automatic refresh over either a set interval or after a set expiry time.
• The server may make use of the view and camera settings that can be sent by Google Earth to serve only a portion of the feed at once.
• The server may not make use of the view and camera settings to serve any content different than just slicing up the feed. For example, angling the camera at 45 degrees should not be displaying active volcanoes instead of earthquakes.

Do note that I am defining the KML feed as being the static file, the static file that contains just the link to the other file that changes dynamically. That would be more akin to an OPML file, which contains links to feeds. However, the dynamically changing KML file is just a plain old file full of points and whatnot. You can save it, open it while offline in Google Earth, and it will work perfectly fine as if it never was from something that gets updated automatically. Using only the dynamic file removes the feed part. On top of that, most feed publishers will be linking to the static file only, since that's the file that users are expected to open to get all the automatic update functionality, and that specific file is already being called the KML feed.

Since nothing stops you from putting multiple links at once in one file, or putting links inside of folders or other geographical features, we also need to specify the difference between a regular KML file that just happens to have some links, a file that acts as a subscription list, and a feed.

• A KML feed contains one and only one NetworkLink object, and no other Feature, Geometry or gx:PlayList objects. It may still contain styling or camera settings.
• A KML subscription list contains one or more NetworkLink objects. These may be placed within any Container, and containers may be nested into other containers. No other Feature, Geometry, or gx:PlayList objects may be used. It may still contain styling or camera settings.

From my reading of Google's KML reference, which describes Google's extensions as well as Google Earth's usage of KML, this should about do it. Subscription lists are allowed to have the equivalent of OPML directories, but cannot contain any equivalent of RSS items or Atom entries.

With those definitions, it is safe to say that yes, Google Earth is indeed a feed reader. As far as I am aware, other planet browsers that support KML like KDE Marble do not support automatic refreshing via NetworkLink, so they cannot operate as feed readers.

KML syndication and RSRSSS

That leaves me with one more question to answer: should I start to feature KML feeds and subscription lists within RSRSSS?

While this feed's title would imply that I only care about RSS 2.0, I regularly feature RSS 1.0 feeds as well as Atom feeds here. I have also mentioned HINA and LIRS a while ago, and regularly feature things that aren't feeds, like OPML outlines and XML schemas, and am planning on mentioning other feed formats.

Most feed readers will only support RSS 1.0, RSS 2.0, Atom 1.0 and OPML 2.0, and I am not taking much risks by saying that only a very tiny portion of people today would be treating the legacy desktop version of Google Earth as a feed reader. Therefore, KML and any other uncommon feed formats that I might mention are just some niche thing that will mainly entertain you, or teach you about some Internet history, but not something that will add more sources in your feedreader.

I want to be neither only quickly sharing the feeds of random blogs, nor only be posting about technologies from a parallel universe. I want a little bit of both. So I will use the following guidelines to decide when to and when not to post:

• Sharing a random KML feed, with some boring data that I don't have much to say about and that you would probably expect within Google Earth, like weather information, is boring.
• Sharing a KML feed of literally Boring data, showing the tunnels currently under construction all over the world, makes for a great pun, so that could work because I can't resist puns.
• Sharing the aforementioned feed, explaining why this feed exists, what it's used for, the script that generates it, or the secret extended data hidden within it, that's a lot better. You might not use it, but it will be interesting.
• Mentioning the existence of a KML version of an RSS feed on the same post, like how I already mention other formats of an RSS feed, is harmless.

As always, if you happen to have any suggestions, questions, comments, contributions, compliments, confusions, conveyances, confessions, confections, complaints, contemplations, conjectures, concerns, commendations, condiments, commiserations, conferments, contradictions, compromises, condolences, contraindications, conspirations, contentions, confabulations, contrarieties, conclamations, confidences, contestations, considerations, confitures, other words to add to this convoluted list, or consternations at said concrescence of commas, feel free to reach out. Especially if you actually read through this whole post and were not scared away by the discussion of a Google product or by the XML examples!

What if instead of having just one person's dreams in your feedreader, you could get the weirdness of a whole community's worth of brains? You can thank the National Dream Center for providing you with a feed that provides just that. You can also get this feed in the Atom 1.0 format.

PS: If you look carefully at the URL, you will find that there is a fid parameter in it. This is a forum ID, and you could get feeds for all the other forums and sub-forums of the National Dream Center. This sounds like an OPML file waiting to happen, but for once, I will abstain myself from making one. The public dreams section is the only truly interesting one anyway. However, the availability of RSS feeds on MyBB forums is definitely something to investigate later.

A while ago, I got an account on Dailymotion because I didn't want to use YouTube to host some videos, and PeerTube was not a thing at all.

Dailymotion is a French video hosting service. I don't even know whether it is well-known outside of France; I remember that it was just as popular as YouTube back when it still had star ratings and a yellow subscribe button. It got overtaken by YouTube and switched its business model to mostly cater to news corporations. But it is still possible for anyone to register and upload videos.

At some point, Dailymotion decided that I, too, was a news corporation uploading videos to embed into my articles, so I got subscribed to a newsletter.

Every quarter, I got an email informing me of the latest updates to Dailymotion's platforms for partners; features that I just did not have access to at all because I am not an actually verified partner and am not giving Dailymotion any money.

Through those updates, I found out that partners can contact Dailymotion's tech support to get them to regularly poll an RSS feed, download the videos listed in that feed, and upload them to Dailymotion. Pretty neat, and obviously right up my alley.

This feature is not available to everyone of course, but some of the documentation is. To allow setting various Dailymotion-specific attributes on the videos, they have devised the dmrss XML namespace. The namespace's URL is also its documentation, which is surprisingly uncommon for XML namespaces as they usually just say "this URL is reserved": https://www.dailymotion.com/dmrss. Of course, I wrote an XSD for it.

Supported feeds must use MediaRSS to provide the basic attributes such as a link to the video, and include some required attributes from the dmrss namespace.

Most of the attributes are meant to set metadata for attribution of music videos, TV shows or movies. Some attributes are more technical, marking the video as private, disabling ads shown during playback, or to request a deletion of the video. They do not use RFC 6721 to mark videos as deleted, a standard that I previously featured in RSRSSS, but that isn't surprising as this Atom extension is not well known, rarely implemented, and is officially only for Atom and not RSS 2.0.

As a French developer, I am used to seeing the common mistakes that French people make when trying to write in English, and I saw quite a few of them in the namespace's documentation. One of my pet peeves is adding spaces before colons and exclamation points, something I am often fighting against at work with the help of other, rare, good English speakers.

But apart from these mistakes and the somewhat unusual table structure to represent attributes within elements, this is not the worst XML documentation I've seen; the worst being of course the complete lack of documentation. So congrats on the Dailymotion team for still using RSS, and still updating their uploader.

If they are still updating it today, then it must mean it is still in use. Feeds won't die any time soon.

This freemium service offers e-mail notifications as well as an RSS feed telling you when a book you placed a hold on is available, or when a book you borrowed is due to be returned. It does so by checking your public library's website once a day or when you browse the site, probably by using some good old scraping.

It mostly supports libraries in the US and Canada, and its "international" category only includes a few libraries from English-speaking countries, so I won't get to use it. But that's okay, I'm glad there's a thing somewhere out there that has been running for two whole decades and still serves feeds!

They provide a demo, showing what the online version and the emails look like. They also include a link to a demo feed, but it doesn't look like this feed is ever updated, so it doesn't demonstrate much.

As I left the fediverse with a rather negative experience, as people remain awful no matter what network you use, I went on Retrospring just to keep one thin connection to the few nice people I knew from there, because many of them were on Retrospring too. It isn't federated and has a smaller user base so I felt less concerned.

A Q&A-based social network is quite convenient for me, by being completely asynchronous and not necessarily encouraging instant and short messages. I can write a novel when answering a question, and it is even possible to write novels in the questions themselves, though that can be disabled because that has caused server troubles in the past. I can take all my time to think carefully about my answer. I can put context. I can decide to just discard a question entirely. I can ignore the website for a few weeks, then come back, and not miss anything because all the pending questions are still there, waiting for me.

With that, there is no fear of missing out. The site gets a lot less distracting because you don't need to be constantly available to reply instantly. More time to think and more space to write means less misunderstandings, so less drama. The design also prioritizes answering your own questions, before interacting with the answers of the people you follow, and way before interacting with the answers of anyone on the website, so it makes it much easier to ignore any drama and harder to cause any drama.

Thanks to this much calmer approach to social media, I managed to stay there for a while. I sometimes took breaks without much issues, other than having to explain to others that I take breaks, since others usually don't need that.

I managed to meet two more wonderful people in there. I talk to them outside of the platform now, and got quite close to them. Those two friends can relate to some of my personal issues or might even help me understand them better. I support them through their bad times, and they support me through my own. Friends I think about every day. Friends I love, rather than just merely like. And for that, I am eternally grateful to the creators of Retrospring.

Retrospring got quite popular recently, with Tumblr, Twitter, Rentry and Fediverse users. So popular, in fact, that its maintainers have decided to shut it down because they couldn't handle it anymore.

That made me discover that they had a blog, so here is its feed, if you want to follow them to the end.

Registrations are now closed, but you can still be part of the club of question askers by asking me questions anonymously if you so wish. Or you can join other instances, because thanks to open-source software, anyone can run their own Retrospring. I already have reserved a spot on Fragsturztaube, an instance hosted by the same person who ran the Fediverse instance I was on before, and I will be moving there once Retrospring.net shuts down entirely. You can send me questions there too; they will sit in the inbox, and I will start answering them in 2025. I don't like having to manage both accounts at once!

No captions are provided, or titles, or locations. It's nothing but stickers. Stickers in various languages, in various cities. It can be a fun little game to try to understand just what each sticker is about.

I subscribed to the feed because I like my feed reader backlog to be sprinkled with random photos. These tiny pieces of litter, of vandalism are now spreading to my digital space.

Since I subscribed, I noticed that when I go outside, especially when I am waiting at a pedestrian crossing, I find myself looking for stickers on the poles or street cabinets. I normally treat stickers as visual clutter and will avoid them like I unconsciously avoid looking at ads (my brain has a built-in ad blocker!), but now I occasionally want to look at them and think about them.

And I am glad that I found a new way to appreciate the little things around me. So thank you, random netizen, for making the often anxiety-inducing exploration of the city a little bit more interesting by letting me stumble upon your Atom feed.

Typing toilet rss into DuckDuckGo is how I stumbled upon PRO Monthly. This is a monthly magazine, but the feed will give you the more frequent news articles from their online version. You may want to subscribe to their print version though, because I can't think of a better thing to read while sitting on the bowl. Or maybe you can put that somewhere in the stack of magazines at the doctor's office and admire the consequences.

If you are one of those weirdos who are not incredibly passionate about porta-potties, then you might still be able to learn something from this feed. You don't need to worry about what you have to say not being worthy of being posted on your blog, because even professionals literally shitpost.

What if there were some good surprises? What if, even though they might not be used realistically, some very interesting computers were starring on a movie? And what if someone was motivated enough to catalog them all?

Starring the Computer lists every computer that has been identified in a movie or a TV show, and rates their appearance by importance to the plot, realism and visibility during the scene. It's quite fascinating to see the variety of computers that are featured. And it has a feed for its recent updates, and has been continuously updated since at least 2007, maybe even before that.

I love these kinds of unexpected small databases that people keep online, even in the current times. Still contributing to the knowledge sharing that the Web was meant for.

A related link that I wanted to share but that has no relevant feed: there are a lot of movies that feature Nmap.

You could spend a while arguing for and against this in your head. My own take on this is that this is unenforceable, and so opposed to the entire point of syndication that it just makes no sense. If you don't want your stuff to be shared, don't share it in the first place.

But you can do better than just a theory. You can put this to the test. Just throw the World Heritage Convention's feeds at your nearest feed aggregator!

They specify that you must get a written permission to syndicate anything from their website. If you republish the feeds they provide, they will give you that permission for free. If you want to republish anything else, you will have to pay, and they can refuse. You are only allowed to change the display typeface, typeface size, typeface color, and linebreaks, and nothing else.

Considering the amount of feed aggregators out there that gladly gobble up anything online and spit it back out onto their own feeds, or the amount of SEO-friendly spam that copies other websites, it is certain that these feeds have been illegally copied multiple times. Search for a sentence found in the description of any <item> and you will find them.

I am waiting for the day I get to feature a decision of the International Court of Justice related to RSS in this feed. Thanks UNESCO.

The Bureau of Meteorology of the Australian government is no exception to this. It provides three RSS feeds per state, all for severe weather warnings: one for land warnings, one for sea warnings, and one for both.

Unfortunately, the BoM seems to start forgetting what RSS feeds are meant for, like many other websites. Their website cannot be accessed from envs.net, probably because its IP address is blocked as it is a VPS. Their website also cannot be accessed from other IPs if the User-Agent header is missing, contains a known HTTP tool like curl, or matches the regular expression https?:/*\w. There are no exceptions configured for the RSS feed URLs or for well-known feed readers.

I generated an OPML anyway, running the script on my own laptop since it can't run on envs.net. You might have better luck than me getting those feeds to work in your reader. And if you don't and are an Aussie, then perhaps you can help make the world a tiny bit better by complaining to your government.

This netbook is one more step in a half-accidental miniaturization of my devices. Every device that newly enters my home seems to keep on getting smaller. We are now down to a 10" 1024×768 screen. I am getting used to this keyboard well, though I am annoyed by the < > key, which is only ⅔ the size of a normal key and in an inconvenient, non-standard place. You are reading some XHTML embedded inside an XML document that I am typing entirely by hand, so I'm sure you can guess that I rely on that key significantly.

But when it comes to making my devices smol, I could go even further. The Sony Vaio P series comes to mind, with its 8" display that has a larger resolution than my current netbook.

I could also try running postmarketOS on a repurposed phone. Or I could get a PDA, running Windows Mobile as that would give me interesting opportunities to mess with the Morgue even further. But those wouldn't exactly be computers, they would be mobile devices.

If I keep to a stricter definition of a computer, then the winners might just be Handheld PCs. As desktops are meant to be on desks and laptops on your lap, those palmtops are for your palm. Soon your entire body will be convered in computers.

There is still a small community of handheld PC users, and new software is still being occasionally released for Windows CE, the OS that Microsoft put on those when they created the brand. It can be found on HPC:Factor. I found it randomly when trying to learn more about some very early support for feeds from Microsoft, before XML was even fully standardized.

I would love to someday get my hands on a Windows CE device and mess with it, especially to learn more about feeds and a strange client-side server-side web programming language. Those two -sides are not a typo. But in the meantime, you can use yet another OPML file to check out the RSS feeds of their website and forums, which include hardware and software reviews, software downloads, and a treasure trove for buying, using, developing and troubleshooting a Handheld PC.

The very first thing that comes to my mind when thinking about how to describe this website is cute. This is also a very fitting word for Mana herself. Despite her believing that she is bad at computers, bad at drawing, or completely uninteresting, we get a cool website filled with pretty visuals where we can discover her and her thoughts, hobbies, creations, and it is just as fascinating as any personal website of the "web revival" movement. Come to find out about idols, Stardew Valley mods, anime and manga full of cute girls, bullet journaling, visual novels, tiramisu, and more.

And of course, as with any time a friend lets me talk them into making changes to their website, there's an RSS feed. She accidentally trolled everyone involved in feed format drama by providing an RSS 2.0 feed named atom.xml. Chef's kiss. That feed includes both the blog posts and the site updates. You can keep track of everything happening on the website, not just the blogging, a difference that many personal website owners forget about.

By the way, she has repeatedly attempted to compliment me publicly on that website, which is of course a crime. You can help avenge me by complimenting her back on her guestbook.

Recalls usually include a photo of the affected product to help consumers identify them. The Twitter account includes those photos in the tweets, but for this bike, the photo of half of a Reblochon cheese was attached instead. This photo came from a different recall that got published almost simultaneously. Of course, it took no time for everyone to notice such a mistake from a governmental account, and a few hours later, the tweet got removed.

I see two ways in which this could have happened. The first would be that someone just uploaded the same thumbnail twice accidentally. However, both of those recalls were made volountarily, without involving the authorities, so they would be submitted by the manufacturers themselves, so those thumbnails may have been uploaded by two different people!

Another alternative, which I see very often in my job, is that a race condition occurred. The code that automatically tweets the recalls probably ran like so:

1. Retrieve the latest recall.
2. Write the tweet.
3. Find a thumbnail for the latest recall.
4. If there is a thumbnail, add it to the tweet.
5. Send the tweet.

In most cases, this will work just fine. But if two recalls get submitted at almost the same time and no safeguards are in place when retrieving the thumbnail, you could get the thumbnail of a different recall:

1. Someone submits a recall for the bike, triggering the tweet code.
2. Retrieve the latest recall (the bike).
3. Write the tweet.
4. Someone submits a recall for the cheese while this tweet code is running.
5. Find a thumbnail for the latest recall (the cheese!).
6. If there is a thumbnail, add it to the tweet.
7. Send the tweet.

Most databases have a concept of transactions that should prevent this from happening, and most developers are taught about this in a database class. However, the trend of modern web development is to not care about the database at all, often with bad consequences. This is one of those consequences, and one that was trivially easy to avoid.

When reviewing code, most of my time is spent thinking about the database queries and imagining situations where this kind of issue could crop up. When testing some code, I also always check the database query history to see if anything weird crops up. Unfortunately, many developers do not have the time or skills to review or test their own code, or their team does not care about reviewing or testing other people's code.

Maybe we should issue a recall for this recall service, because the confusion from the thumbnails could lead to misidentifying a recalled product?

Anyway, here's something nicer about Rappel Conso, something finally relevant for this feed. It provides RSS feeds! /rss gives you every recall, /rss?q=fromage gives you every cheese recall, and /rss?categorie=0112 gives you every recall of frogs and snails. This is France after all.

As is custom here, I made an OPML file to list the feeds of the 70 categories and subcategories. I did not try to put every single possible search query, or the file probably wouldn't fit in this universe. I suppose you can use it if you are a very paranoid person buying products in France. Have fun panicking!

Their tagging is also more detailed than average, making it easy to find manga of a specific topic, skip the ones that you know you won't like, or find the right meme to repost somewhere. Or the tags themselves can be the memes. Like long titles? Like hand-holding? Would you like to become bread?

For this week, I was looking at the feeds of a different website, one that I would have never expected to possibly feature on here. I wanted to state that RSS too, is yuri, to follow a meme that I commonly see on the Fediverse. And while doing so, I wondered if I could find an actual yuri feed. Turns out Dynasty has two Atom feeds for the most recent chapters, sorted by official release date or sorted by the date they were added to the website.

So there we have it. RSS too, is yuri. Another excellent argument in favor of RSS.

On multiple occasions in the past, I have heard that the main motivators for most of the innovation in computer hardware are the video games and porn industries. This was before artificial “intelligence” ruined everything of course. We have mentioned video games in the past on RSRSSS, notably with the Grab Free Games post, but we have yet to see porn.

We came close to it last week with the Dynasty Scans feed, as a lot of their tagging revolves around sexual content. People are specific about their kinks after all. But I had featured that feed while I was researching whether porn sites had any RSS feeds, so here we are.

Pornhub advertises only one feed through RSS Autodiscovery, for featured videos. But there are more. I also found a feed for the latest videos, and a feed for each category.

The titles for the category feeds are missing a space, so the lesbian category feed is titled LesbianRSS, which inspired me for last week's post about RSS being yuri.

The feeds use a bunch of non-standard tags with no XML namespace that will probably not be understood by any feed reader: thumb, thumb_large, duration, embed and keywords. That's sad, they could have used Media RSS for this. That would have made the feeds PSP-compatible, ignoring the SSL issues, or compatible with many podcast players. You could still combine a feedreader with yt-dlp and achieve the same thing anyway.

I made an OPML file for all of the feeds that I could find, in all available languages. This totals to 1320 feeds. Not bad.

What a better way to end the year than to prove once more that RSS is neither dead nor only for blogs by showing it is also for porn? Finally, the joke pronounciation for RSRSSS as /ɑɹsɑɹs/ (arse-arse) has some truth to it.

Last year's last post might just be the best opportunity I can have to discuss one of the few niche features of the RSS 2.0 specification: the <rating> element. The current specification barely mentions it under the optional channel elements section, and just barely describes it as the PICS rating for the channel. The RSS Profile, a set of recommendations on how to write feeds or implement feedreaders, has more details.

PICS was an attempt by the W3C to provide a standard way to do parental controls. Websites can use the PICS-Label HTTP header, or <meta http-equiv="PICS-Label" content="…" />, to add an advisory label to their website. Starting with RSS 0.91, this label could also be specified in an RSS feed.

Advisory labels use a cursed Lisp-like language to describe how a website rates against a rating system. A PICS rating system is equivalent to the ESRB or PEGI ratings you see on video games: it defines one or more scales to rate a website's contents, for example on adult content, drug use, gambling, etc. The idea behind PICS is that a website can rate itself against one or more systems, then parental controls on the web browsers can be configured to allow or deny some ratings based on these judgements.

Internet Explorer is the only web browser known to have implemented this, from IE 4 to 7. IE 7 just so happens to be the version that introduced the Windows RSS Platform, so it might be the case that it implements supports for PICS ratings; this is something that I will have to test later. This article provides details on PICS and its implementation in IE, with screenshots and code samples, if you want to learn more.

You could use PICS to rate websites and feeds against anything, but of course it was mainly intended for the usual suspects of parental controls, the things that scare American christians: vulgar words, naked human bodies, sexual education and violence. Drugs, gambling or other addictive behavior were less of a concern to the lobbyists at the time, though some later rating systems included that.

Most websites did not care about rating themselves, the external rating agencies that provided APIs to rate websites without their intervention are mostly American, and the feature was only available in one browser, so it was not very popular. But it had another significant effect, which I will explore later.

For now, I have added a PICS rating to this feed. If you are viewing this feed on a browser that does not support RSS natively but supports XSLT, you can read it in its full S-expression glory at the top of the page, under the About this feed section. For everyone else, you might want to just view the source of the page.

RSRSSS ratings

Note that these ratings only apply to the entire feed and not necessarily to the links it contains. One flaw in the PICS integration into RSS is that it is not possible to rate items separately, so I am going to conveniently ignore last week's post.

RSACi version 1

This is the rating system that was provided as a RAT file starting with Internet Explorer 4 on Windows 98.

Violence

Level 0 (No violence): There is no depiction of violence per their definition.

Sex

Level 0 (None): There is no sexual activity portrayed per their definition.

Nudity

Level 0 (None): There is no nudity per their definition.

Language

Level 1 (Mild expletives): I do not like using them much in my writing, but I have used some mild words that some language filters could block, like bullshit.

ICRA version 3

This rating system was included in Windows XP and enabled by default. The RSACi one was still available but disabled. The PICS definition already describes PICS as outdated: for use in legacy PICS-based systems.

Nudity

Level 0 (None): There are no bare buttocks, breasts or genitals. That would probably boost my audience though.

Sexual material

Level 0 (None): There is no sexual material per their definition. The Internet has however taught me that anything can be someone's fetish, so maybe someone is getting turned on by this feed. Syndicate me daddy!

Violence

Level 0 (None): There is no assault, rape, injury, torture, killing, blood or dismemberment here. Syndication has nothing to do with Assassin's Creed Syndicate.

Language

Level 1 (Limited): As mentioned above, I said bullshit before, which could scare the puritans, so there is some mild language. When there is some, I should be using level 2 (Some), unless this is only in an artistic, medical, educational, sports or news context. I have been described as an Rsszard of Syndication before, and magic is often described as an art, so this is definitely an artistic context. You may also learn some stuff or get some news about syndication here, so it also counts as an educational and news context. Level 1 it is.

Depiction of tobacco use

Level 0 (None): You don't need to smoke to use feeds.

Depiction of alcohol use

Level 0 (None): You don't need to poison yourself to use feeds.

Depiction of drug use

Level 0 (None): You don't need to do drugs to use feeds.

Depiction of weapon use

Level 0 (None): You don't need weapons to use feeds, unless someone is insisting that RSS is already dead.

Depiction of gambling

Level 0 (None): I bet on RSS as a good tool for the Web, but there is no gambling here. Syndication has nothing to do with The Syndicate.

Content that sets a bad example for young children

Level 0 (None): Using RSS is definitely a good example. Young children should be brainwashed into using RSS as early as possible so that they can fix what the previous generations did to the Web.

Content that creates fear, intimidation, etc.

Level 1 (Limited): The previous statement probably somewhat sounds intimidating, and because I often delve into unknown and cursed technologies, especially those that involve XML, it can provoke fear. As explained for the Language rating, this is in an artistic, educational and news context, so this stays at level 1.

Incitement/depiction of discrimination or harm

Level 0 (None): Though I have my own preferences, all feed formats are welcome here. We don't discriminate between feeds.

User-generated Content

Level 1 (Limited): There technically is user-generated content since there are links everywhere to external feeds, but it is curated, thus moderated.

TICRF version 1

This is a Taiwanese rating system that also shipped with Windows XP, but was disabled by default. Adding it also requires doing some extra configuration because Internet Explorer's Content Advisor did not support Unicode properly. I added this rating by translating every level in Google Translate, so this is far from perfect. It only has levels 0 and 3: there is some bad content or there isn't.

Language (網站內容語言之使用)

Level 0 (18歲以下者可單獨閱讀或由家長陪伴閱讀之容許語言): There is no explicit language. This sounded like a much stricter definition than the more nuanced language filters from other systems.

Sex or nudity (性與裸露之圖文或多媒體)

Level 0 (完全無裸露及在父母陪伴之下可觀看): There is no sexual content or nudity. Of course, last week's post about a porn site is questionable, but the contents of RSRSSS itself are not something that would turn it into a restricted site entirely.

Violence (暴力與流血之圖文或多媒體)

Level 0 (完全無暴力或可由父母陪同觀看之虛構暴力及運動暴力): There is no violence or bloodshed.

Other (其他)

Level 0 (在父母陪同下可閱讀之其他內容): There is nothing else that should not be seen by individuals below 18 years old without parental supervision.

Devever Content Ratings

This is an example rating system that was published along with the article about PICS that I mentioned earlier. It of course doesn't ship in Windows, but you can add its rating file to the Content Advisor.

Cats

Level 0 (No cats): There are no cats depicted in this feed. Do note that one feed of sandcats was once mentioned, but that's a separate site with its own rating, and you are warned that they are cute. Click at your own risk.

Connector Mating

Level 0 (No connector mating): We don't plug things into things here, we only use things already plugged into things to transfer feeds.

Disturbing Technology

Level 2 (Serious kludges): Some of the technologies that I explore here can be quite cursed. PICS is probably one of these, considering it puts S-expressions into an XML file and is quite obsolete. So I suppose that some may traumatise the reader for a few hours.

Esotericism

Level 3 (Critically endangered knowledge): It is a very real possibility that some of the technologies I describe here are so obsolete that a few people dying may make the knowledge of them disappear. One old post comes to mind about HINA and LIRS, two syndication formats introduced in Japan before RSS took over. Those are so old that they were not well indexed in the Wayback Machine, so there is some knowledge that is likely only in the minds of the few people involved in it.

Rantiness

Level 1 (Mildly acerbic): I have been described as acerbic once, though not in the context of RSRSSS. I have repeatedly expressed some frustration here, that's for sure.

If you know of any additional rating systems that I could use, preferably with an existing PICS rating service document, feel free to reach out. I might rate my feed against them and add to the <rating> element that nobody will ever use on this feed, just to provide a good example of it and preserve it a bit more.

• learn about RSS;
• find out whether word games are good for your brain;
• troubleshoot ID10T errors;
• get Minecraft house ideas;
• get the best Minecraft mods;
• get the best Skyrim mods.

That is definitely what you were looking for by browsing Lenovo's website. And I suppose their attempt at SEO boosting might work, since Google has been returning complete nonsense as their search results ever since they put AI in there, and they can't even figure out why because they cannot even consider the possibility that they shouldn't use that to rank search results. It's incredible to see just how so many Silicon Valley people are quickly rewiring their brains to be even less intelligent that those artificial, pretend, fake intelligences.

I can't wait to watch this whole thing burn. In the meantime, I will just keep on writing XML documents and XML processing scripts entirely by hand. And next week, we'll look at yet another RSS extension from a better era of the Web.

One of those APIs was the Yahoo Weather API, which provided weather information as an RSS feed. To do so, they were using their own custom XML namespace. I was much too young to know or care about APIs back then, but I have seen it repeatedly in a bunch of lists of XML namespaces found in RSS feeds. I looked a bit deeper into it, because of course I had to.

I have gone through the archived documentation for the Yahoo! Weather RSS feeds from 2007, on a site more lightweight and more readable than most modern websites, and wrote my own XSD for it. So if you want your RSS feeds to include Yahoo! Weather-compatible weather data, have a look at the schema.

And of course, the XSLT that shows you a neat webpage when you open this feed with a browser that does not natively support RSS now handles this namespace, so you can check out a fake weather report at the end of this post and some metadata in the About this feed section in the header.

Reference

The recommended name for this namespace is yweather, and its URL is http://weather.yahooapis.com/ns/rss/1.0.

<yweather:location>

The location where the weather conditions are being reported. This is intended to be used in a <channel> element.

Note that the Yahoo! Weather API was also repeating this location in <item> elements as GPS coordinates using the Basic Geo Vocabulary. They could have done so on the <channel>!

city

Name of the city whose weather conditions are being reported.

region

The state, territory or region, if there is one. May be empty.

country

The country that the city belongs to. This is documented as being a two-character country code, but it might not be.

<yweather:units>

The units of measurement used in this report. This could be controlled with the u query parameter, to be set to either c for Celsius degrees and implicitly metric units, or f for Fahrenheit degrees and implicitly wrong units. This is intended to be used in a <channel> element.

temperature

The unit of temperature, either c for Celsius degrees or f for Fahrenheit degrees.

distance

The unit of distance, either km for kilometers or mi for miles.

pressure

The unit of pressure, either mb for millibars or in for psi.

speed

The unit of speed, either kph for kilometers per hour or mph for miles per hour.

<yweather:wind>

The current wind conditions. This is intended to be used in a <channel> element.

chill

Integer. The wind chill, the perceived temperature as influenced by the wind, in the chosen unit of temperature.

direction

Integer. The direction in which the wind blows, in angular degrees from 0 to 359.

speed

Non-negative integer. The speed at which the wind blows, in the chosen unit of speed.

<yweather:atmosphere>

The current atmospheric conditions. This is intended to be used in a <channel> element.

humidity

Integer. Relative humidity, in percent, from 0 to 100.

visibility

Non-negative integer. Visibility, in hundredths of the chosen unit of distance. One kilometer or one mile will be expressed as 100.

pressure

Non-negative decimal number. Barometric pressure, in the chosen unit of pressure.

rising

Integer. The current trend of the barometric pressure:

0

Steady barometric pressure

1

Rising barometric pressure

2

Falling barometric pressure

<yweather:astronomy>

The current astronomical conditions. This is intended to be used in a <channel> element.

sunrise

The time of sunrise for the current day, in a h:mm a format per Unicode Technical Standard 35 Part 4, for example 6:54 am.

sunset

The time of sunset for the current day, in a h:mm a format per Unicode Technical Standard 35 Part 4, for example 9:37 pm.

<yweather:condition>

The current weather conditions. This is intended to be used in the <item> element. It should be unique within this element.

text

Human-readable name of the current weather conditions, for example Sunny.

code

Non-negative integer. A code for the current weather conditions. For example, 0 for a tornado, or 46 for snow showers. Refer to my XSD or to the archived documentation for a full list of codes.

temp

Integer. The current temperature, in the chosen unit of temperature.

date

The date and time for which the current weather conditions apply, in a EEE, dd MMM yyyy h:mm a zzz format per Unicode Technical Standard 35 Part 4, for example Sat, 20 Aug 2011 6:54 am PST.

This is very close to the RFC 822 section 5 format used by RSS feeds, but with a 12-hour clock and with different timezone names, for example CET for Central European Time where the RFC only allowed some American time zones. This same format is being used in the <lastBuildDate> element of the <channel> and in the <pubDate> element of the <item>, causing all Yahoo! Weather feeds to be invalid.

<yweather:forecast>

The forecasted weather conditions for a future day, as of the time of publication. This is intended to be used in the <item> element, and can be repeated to share forecast information for multiple days.

text

Human-readable name of the forecasted weather conditions, for example Sunny.

code

Non-negative integer. A code for the forecasted weather conditions. For example, 0 for a tornado, or 46 for snow showers. Refer to my XSD or to the archived documentation for a full list of codes.

low

Integer. The lowest forecasted temperature, in the chosen unit of temperature.

high

Integer. The highest forecasted temperature, in the chosen unit of temperature.

date

The date of the day for which the forecasted weather conditions apply, in a dd MMM yyyy format per Unicode Technical Standard 35 Part 4, for example 20 Aug 2011.

day

The weekday for which the forecasted weather conditions apply, in the eee format per Unicode Technical Standard 35 Part 4, for example Sat.

Examples

Check the source code of this feed. The RSS item you are likely reading this from includes an example of the <yweather:condition> and <yweather:forecast> elements. The channel also includes <yweather:units> and <yweather:location>, but not the others because I just can't be bothered to make up some current weather conditions every time I update this feed.

For more examples, you may want to check out whatever has been committed to GitHub featuring this namespace. This is usually how I learn about dead XML namespaces even when they are not documented.

I had mentioned this again when I shared The Cramped's feed, and it is through that blog that I discovered Analog Office, a blog dedicated to all things stationery.

My thing is usually notebooks, but a blog that discusses stationery in general can be interesting to widen my horizons. With this blog, I learnt about automatic numbering machines or adding machines, and got some great reminders to use the good notebooks, rely on notebooks to blog more, or to practice morning pages. This blog also discusses various techniques to organize papers like the action file and the tickler file, which I recommend if you deal with a lot of paper daily.

One thing I particularly like about this blog is how pragmatic most of the advice feels. This is definitely aimed at those who involve a lot of paper in their lives, but it does not go so far as to say you should spend your entire time doing nothing but writing notes and filing them somewhere, as you might see from Zettelkasten aficionados. In a Zettelkasten, it is only if you spend an inordinate amount of time filling it that you might start to reap some benefits from it, and that only works for specific kind of endeavours like conducting academic research. Most people should not use this. On the other hand, simple tricks like the interest grid will be useful for most people.

To think well, you need both good raw material, good “food for thought”, as well as the right tools to think properly, such as being aware of logical fallacies, going through therapy, etc. This is true for any kind of thinking, be it described as rational, abstract, practical, or creative.

The value of the products of our imagination depends of course on the number, accuracy, and clearness of our impressions, on our judgment and taste in selecting or rejecting the involuntary combinations, and to a certain extent on our power of voluntarily combining them.

—Charles Darwin, The Descent of Man, 1871
cited by Maria Popova, Darwin on How to Evolve Your Imagination, The Marginalian, 2025-01-26

I have cared about my information diet for a while, long before I heard of this concept. When I left my parents' home and was no longer required to watch the news on TV at every meal with them, my view of the world had slightly shifted, as some unhealthy part of my diet got removed. I have occasionally watched some news on TV since them and I do not regret not owning a TV at all.

I also keep some surprisingly good memories of the quarantine in 2020. While that can be attribute to multiple different factors, consciously deciding to stay away as much as possible from reading any news about that pandemic other than any official government instructions protected me from a large amount of anxiety.

Much more recently, as I learnt about this concept, I started asking myself whether something would be good, or is still good, for my information diet. With multiple international conflicts, as well as the least interesting yet most influential country of the West sliding into fascism even further, caring about one's information diet becomes more and more important.

I only use social media that either does not mention any topic that may poison my brain, particularly by triggering unnecessary negative emtions, or that gives me a lot of control over it. I block any terms that may be triggering to me, stay away from people who engage in constant Internet drama or share too many news articles, etc. I had to unsubscribe from a feed or two recently as they succumbed to a wave of American despair.

But caring about the information diet is not just about removing the bad stuff, it's also about adding more of the good stuff. And it is with this in mind that I share here a feed that I subscribed to recently, The Marginalian.

It's not easy to find a feed from my own subscriptions that inspires me enough to share it on RSRSSS. Most subscriptions have become so normal that I might forget their true uniqueness or value. Instead, I keep a separate list of ideas of feeds to share instead, or of XML namespaces to explore, etc., and add to that list when I stumble upon a feed that inspires me even if it might not be something that I would subscribe to. But this feed fits the bill perfectly, as you may notice from the unusual length of this article.

Since 2006, Maria Popova, a Bulgarian writer, shares on this blog originally called Brain Pickings some food that my brain found to be exquisite. Irregularly, but multiple times a week, Maria will share something thought-provoking, insightful, often on ideas such as the meaning of life, art, spirituality, love, etc.

Most articles are a discussion of a book, be it a very recently published book with some contemporary takes, or a long-forgotten book of the previous century. But while the age of those books can be felt in the numerous quotes scattered throughout those articles, what they tell us is often still valid in the current age, or perhaps even more direly needed than before.

This blog runs on WordPress, so it is rather easy to build many feeds from it, for a search query or a category. But most articles are using at least half of the available categories, so filtering by category is not particularly useful. I just stick to the main feed.

I let my brain monch all of the good stuff during moments of calm, with little fatigue, when it might be the most receptive. If I find something to sound particularly interesting, to maybe relate to some other ideas I've had, I save some quotes in a random text document, and let them stew for a while. I come back to them when I feel ready to reflect on those properly, copy them in my journal, and write about them.

A great metric for how thought-provoking something is to me is how much I will journal about it, and any quotes I take from reading this blog have been some of the most productive ones. Just yesterday, I wrote 14 journal pages, an unusually high number, with at least 10 related to quotes from this blog combined with fascinating conversations with Mana.

This blog is helping me coalesce some thoughts on various topics such as why I want to move to another city, where I want to move, what I am looking for in a city, what I live for, why I blog, why I get an urge to photograph cities, what I look for in friendships, dealing with being mostly alone, my sexuality, mindfulness, or the information diet itself. And I have barely started digging, both through the blog's thousands of articles and through my thoughts related to them.

I encourage you to, if you haven't already, pay attention to your information diet. Think about what you are feeding your brain, be it what feeds you subscribe to, how you read them, or what things you experience in the rest of your daily life, as well as how much. Experiment in adding, removing some sources, or changing how, when, where you process them, and see if there's any change in your life. It is likely that you can take some weight off your shoulders just by paying attention to how information is making you look at your own life. And perhaps, you might find that The Marginalian brings some good to you too!

I built this thanks to the extra APIs provided by Extension:SiteMatrix, a MediaWiki extension. The sitematrix API action that this extension adds lets me list all of their wikis in all their languages in XML, so that a script can access every wiki and look for any <link rel="alternate" /> links, to find the feeds through RSS Autodiscovery.

There are more ways to syndicate content from WMF, so I will have to come back to those wikis some other time.

To get the feed synchronized properly, use your own starting date in ISO 8601 format to build your own feed URL:

http://interconnected.org/more/davinci/YYYY-MM-DD.rss

This is a rather cool idea. You could probably do this for other books, for PDFs, or any sequence of anything that can be included in a feed. I would like to see this for podcasts for example, as a way to slowly catch up on an existing podcast. If anyone ever creates such a tool, or one already exists, let me know.

I still have a lot to mull over about this, and I hope that Mana will blag about this so I can have even more food for thought. But an answer that came out almost instantly was contributing to humanity's knowledge. Mostly, making existing knowledge on domains that I care about more discoverable, available, accessible. I think most of my projects fit into this:

• My now defunct French blog had dozens of articles that dug deep in some technical details of some of my other projects, and I know that I taught some concepts to other people, particularly about SQL or GIS.
• My wiki has plenty of documentation and links to other documentation on various technologies.
• I recently started contributing to the File Formats Wiki with my knowledge of some obscure file formats.
• RSRSSS also fits this perfectly, by sharing random feeds, documenting feed formats, XML namespaces, etc.
• Even blogging or journaling, could fit this, since I am expressing my thoughts, thoughts that others might not have, a view of the world other than theirs.

I don't need to be remembered specifically; I expect to be forgotten like the vast majority of humans, and I do not desire popularity, but I would like to help someone access the knowledge. Maybe they will be someone greater than me, and will be able to do something with it.

At times, thinking about what would be left after I disappear from this world lead me to some far more depressing thoughts about death itself. But overall, I feel more stressed than depressed. There is so much knowledge left for me to share. I have so many notes, so many ideas, so many unfinished projects, and so little time. If I were to disappear right now, there would be so much waste.

I don't want to disappear now, and there is nothing in my current situation that would predict an imminent death, but I still have to consider the possibility. Reading about meditation led me to various Buddhist concepts, like knowing that death is a part of life and cannot be avoided. Also related is memento mori. Ignoring the possibility of disappearing now would just be fooling myself.

There is an easy way to reduce some of this stress, and that is to just publish everything to immediately make even the least developed notes I have available. It might not be perfect, but it's still something, some form of legacy, and it can still help someone.

For probably a few years now, I had on envs.net's HedgeDoc instance some notes that could probably lead to a hundred more RSRSSS posts. Feeds, feed formats, links to documentation, links to lists of even more formats and standards and namespaces, questions, rants, etc. I already had the idea of sharing those in some way somewhere for a while, but didn't know how I could shape that. This recent anxiety over my legacy turned this idea into a Problem.

Of course, I ended up manually typing up yet another RSS feed about RSS feeds. Say hello to STRSS, Superficial Thoughts on RSS.

This new feed contains anything and everything. Notes, links with or without context, books, scientific papers, opinions, outlines of future posts, etc., but most importantly, lots of rabbit holes to fall into. Watch out for that! There are no publication dates, no particular order, and it will be updated randomly whenever I feel like it.

I could have used an OPML file for this, or even just a normal HTML page, or a direct link to my Markdown note on HedgeDoc. But I prefer to have this file stored in the same Git repository as the main feed, and OPML outlines are not well suited to writing longer paragraphs, drafts of posts, filled with HTML tags. Writing RSS items also means I do not have to convert between formats when publishing something, and I can reuse the XSLT I have for RSRSSS there. And since there is no more HedgeDoc, it also means I can work entirely offline, which is definitely a great thing in this over-connected world.

I'm not sure how to end this post, so I will just let you admire the STRSS logo:

Well, the ISO delivered. Their website is always hard to navigate, but with enough digging, I did find a feed of the latest updates to ISO standards. You'll need to know by heart how the whole standardization process goes because they will give you no useful description! You'll get to watch standards move towards stages designated by two numbers, with no explanations as to what those numbers are, even though they do have some documentation on that.

But well, at least they've got a feed. With the constant battle I am having with so many websites to find their feeds or build my own, which got quite intense this week as I did some maintenance on a large feed generator, that's quite an achievement already.

I found this blog by checking my own feed reader, as a friend had shared a link to it on the previously featured Linkbudz, along with a remark that this blog pretends to be original when it's not. There have been plenty of feed-only blogs over the years and some tilde friends and I had made our own too.

I really only wanted to feature this particular blog, even though it appears to now be inactive, because one common feature with all of the feed-only blogs that I have encountered is that they all assume they are unique. Those blogs are so difficult to find, so niche, that they just cannot find each other. That is a little sad, and leaves me wondering whether we should have some "feed-only" category or tag in blog directories.

I imagine there could be some interesting developments if this type of blog got a bit more popular or at least got its smol community. That would probably keep those blogs active for longer, because the bloggers would realize that they had an audience!

I wrote last week's post while on a train to Strasbourg, and I'm spending the week here. I found a really cool picnic spot here, in front of the river, with very little people passing by or sitting. I had a nice simple lunch here, resting a bit after some hectic few days where I took a lot of photos.

I remembered that RSRSSS is a thing and that I should post something this week. Since I like to look at feeds related to where I am, like at a library or on an empty highway, I tried to think of something local. And well, the European Parliament is currently taking a good half of my field of view here.

It turns out they have plenty of RSS feeds, in plenty of languages, since the European Union is the leading employer of translators in Europe. So, with tank on my lap, in the sun, I wrote a script and got yet another OPML.

Perhaps you will find something to enjoy in the middle of 2736 feeds of European politics, and in the meantime, I will put everything back into my backpack and sail away on my scooter to keep exploring Strasbourg. I might cross the German border this afternoon, we'll see.

I haven't found any feeds using this, not even any from the archived Discovery Channel store, or any feed software that supports this. If you know of any, definitely let me know.

Reference

All of the elements defined below are to be used within an RSS 2.0 <item> element.

<ecommerce:listPrice>

Required. Contains the current price of the item, a decimal number. This can have an optional attribute:

currency

Optional. The ISO 4217 currency code the price is expressed in. Defaults to USD.

Note that the original specification includes an example where the number is expressed with commas as the English decimal separator: 1,200.00. I chose not to consider this valid in my XSD, as this just allows any string representation of a currency for display instead of using regular numbers that are easier to parse by machines.

<ecommerce:SKU>

Required. Stock keeping unit, an internal reference for the product, which can be any string. This can have an optional attribute:

UPC

Optional. A Universal Product Code for this product. Any UPC format is accepted.

<ecommerce:auction />

Optional. Specifies that this offer is an auction and provides some details about the auction through some attributes:

bids

Required non-negative integer. Number of bids that the item has received.

endDate

Required. An RFC 822 date and time for the moment the auction ends.

buyNowPrice

Optional decimal number. The price for skipping the auction and buying the item now.

currency

Optional. The ISO 4217 currency code the aforementioned buy now price is expressed in. Defaults to USD.

<ecommerce:condition>

Optional. The condition of the item, as one of three options:

• new
• used
• refurbished

<ecommerce:manufacturer>

Optional. Name of the manufacturer of the product. This can have one optional attribute:

model

Model name or identifier for this product.

<ecommerce:mass />

Optional. Mass, or perhaps weight of the item.

unit

Required string. Unit in which the mass or weight is expressed.

weight

Required decimal number. Mass or weight of the item.

This element is not described in the original specification as specifying the mass of the item, but the weight attribute is documented as specifying the weight of the item, so it sounds more likely that this expresses a weight. To clarify this, you could use GeoRSS with an SRS corresponding to the celestial body you are weighing the object on, and use newtons as a unit of actual weight.

<ecommerce:offerPrice>

Optional decimal number. Modified price for the item for a temporary offer.

currency

Optional. The ISO 4217 currency code the price is expressed in. Defaults to USD.

<ecommerce:promoText>

Optional string. Some marketing text to promote the item, typically a single sentence. This can have an attribute:

type

Content type of this element, either plain or html. Defaults to plain.

As this element can only contain a string, any HTML content must be encoded with XML entities or with a CDATA block.

<ecommerce:rating />

Optional. Some sort of rating or score for this item, expressed with two attributes:

possible

Required non-negative integer. The highest possible score or rating.

scored

Required non-negative integer. The score or rating for this item.

<ecommerce:shipping>

Optional. A string providing some information about the shipping conditions.

<ecommerce:size />

Optional. The dimensions of the item, expressed through four attributes:

unit

Required string. The unit in which all dimensions are expressed.

width

Optional decimal number. The width of the item.

height

Optional decimal number. The height of the item.

depth

Optional decimal number. The depth of the item.

<ecommerce:stockAvailability>

Optional. Whether or not this item is available in stock. Only two values are permitted:

• available
• out of stock

An additional attribute can be used:

quantity

Optional non-negative integer. Quantity currently in stock.

Example

<rss
  version="2.0"
  xmlns:ecommerce="http://shopping.discovery.com/erss"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="
    http://shopping.discovery.com/erss
    https://envs.net/~lucidiot/rsrsss/xsd/erss.xsd
  "
>
  <channel>
    <!-- ... -->
    <item>
      <!-- ... -->
      <ecommerce:listPrice currency="EUR">1337.42</ecommerce:listPrice>
      <ecommerce:SKU UPC="2137-420-1312">123456</ecommerce:SKU>
      <ecommerce:auction
        bids="4"
        endDate="Fri, 28 Mar 2025 21:37:42 +0100"
        buyNowPrice="2137.42"
        currency="EUR"
      />
      <ecommerce:condition>refurbished</ecommerce:condition>
      <ecommerce:manufacturer model="ERSS">Discovery</ecommerce:manufacturer>
      <ecommerce:mass unit="firkins" weight="2.3" />
      <ecommerce:offerPrice currency="EUR">1312.69</ecommerce:offerPrice>
      <ecommerce:promoText type="plain">Add some consumerism to your feeds now!</ecommerce:promoText>
      <ecommerce:rating possible="7" scored="5" />
      <ecommerce:shipping>Instant delivery over the information superhighway</ecommerce:shipping>
      <ecommerce:size
        unit="millifurlongs"
        width="4.971"
        height="4.971"
        depth="4.971"
      />
      <ecommerce:stockAvailability quantity="999999">available</ecommerce:stockAvailability>
    </item>
  </channel>
</rss>

It is often said that RSS is dead, for various reasons, usually wrong. One of those reasons can be that because there is no innovation, no new features, no new use cases for RSS appearing, then it's dead. The kind of people who believe this are probably also the kind of people who write a new JavaScript framework every fortnight or buy the latest iPhone every time. I've been told this is a very American behavior, of always wanting to have the latest newest shiny thing to show off, even when it is inconvenient or unaffordable.

It's true that I don't see many innovations happening around RSS, but focusing on all that already exists and hasn't been used tells me there isn't much to add. However, if you focus only on how RSS users use RSS and what they use, you can get some new ideas, and innovation can still happen. It doesn't move fast, it doesn't break things, it just slowly improves things.

Andre Garzia, author of BlogCat, a browser extension that combines a feed reader and a microblogging tool, faced a problem that I too sometimes have. It's common nowadays to browse your RSS feeds on both your phone and your computer, and depending on what you follow and how you consume your feeds, you can't always use some feed reader server like Tiny Tiny RSS or FreshRSS. Without a centralized feed reader, how do you keep the feeds in sync?

This is why BlogCat now includes a feature called OPML matching, basically git diff for your feeds, through the OPML import/export feature available in the vast majority of feed readers. Give BlogCat the OPML from another app, and let BlogCat subscribe to any feeds that it didn't already have, then import a new OPML into your other app that includes the feeds BlogCat has and your app didn't. It's simple, and it works.

I would like to see this kind of feature in my feed readers too, especially as I am using multiple computers with multiple different readers and operating systems. But considering some of those are not updated anymore, or will probably not get any new features added, I'm better off trying to make my own thing.

It's possible to implement a crude OPML synchronization tool with some existing shell utilities:

xidel --xpath 'fn:distinct-values(//outline[@type="rss"]/@xmlUrl)' export1.opml | sort > urls1.txt
xidel --xpath 'fn:distinct-values(//outline[@type="rss"]/@xmlUrl)' export2.opml | sort > urls2.txt
comm -3 urls1.txt urls2.txt

But it takes some creativity to imagine that this could be something a feed reader itself could do, and to make it happen. Well played. I will definitely subscribe to Andre's blog (RSS 2.0, Atom) and hope to see more cool ideas.

Here is yet another OPML file, for one of my own projects, called the International Transport Safety Bureau. This was my first large RSS-related project, started in late 2019, and it's still online and maintained.

I keep a non-exhaustive list of official syndication feeds there, from various government agencies around the world dedicated to technical investigations of accidents and incidents in various means of transportation. But many of those websites do not provide any feeds, or any means of accessing their data programmatically, so I also have to resort to building my own, and that's most of the work in this project.

67 custom feeds are built daily, then both the official and custom feeds are converted to many other feed formats, resulting in 462 feeds being currently served. I could probably double this number by adding the various agencies that I have found but have not yet build a scraper for, and double this again by adding support for even more syndication formats.

The process that builds all of this is a complete mess of meta-meta-programming that would probably make many developers cry:

1. I define sections, agencies, feeds, and how to build or where to find those feeds through one XML file, which follows this XSD.

2. A cron job starts a bash script.

3. The bash script runs the XML file through one XSLT, which generates another XML file that looks like the original one, but with many additional feeds, for automatic conversions of my defined feeds to other formats. This is the script that takes me from 28 official and 67 custom feeds to 462.

4. This longer XML file is sent to another XSLT. This creates a new long Bash script that contains lots of commands to build the many custom feeds and convert in all formats.

5. This Bash script is immediately executed. It will perform a great many tasks:

   • Check that various dependencies are installed.
   • Use a lock file to ensure only one instance of the generator can run at a time.
   • Test the SSL certificates of various feeds that I have declared as having SSL certificate verification issues. If they are working fine now, I get warned so I can re-enable the verification.
   • For each feed, run any of the instructions that I had specified in the XML file. This includes retrieving data with curl, converting HTML to JSON using pup, converting between JSON and XML using xmltodict, processing JSON through jq, and sometimes just calling random shell commands if I need something very specific.

6. The long XML file is run through a few more XSLTs to generate the homepage automatically, as well as today's OPML file, and some other formats that I will have to dig into some other time here.

This is a mess, but it's my mess, and it uses lots of cursed technology that I enjoy, so I think it's great. And it has worked for nearly 6 years now!

Since my discovery of Xidel and XQuery, I have been trying to simplify some parts of this and reduce the dependencies by rewriting the feed generators in XQuery any time I need to do some maintenance on any of them. This brings some performance improvements since I no longer have any Python in the pipeline, I do not need to do round-trips between XML and JSON, and I can do everything with one process per feed instead of a complex shell pipeline.

There will still be some custom scripts in some places, for example to download a large data dump from the NTSB, but I should be able to eventually somewhat simplify the project, which should then let me complicate it more with even more formats and cursed ideas.

As a final anecdote, the issue tracker for the project has an external cause:politics label. I have seen the effects of China's pressure on Taiwan as some feeds were temporarily offline, and had to remove some Lithuanian feeds due to the Russian invasion in Ukraine. This is the only project I have that can be easily affected by random international conflicts like this, and it surprises me every time it happens.

With this, most of the people I knew there have either stopped using Retrospring entirely or switched to various instances in ways that make them hard to track down. I don't want to deal with all the moderation drama going on on the remaining instances due to the hordes of out-of-control Rentry users, and I don't want to waste time with switching instances constantly while losing all of the previous answers I posted. So I made my own thing.

One of the features that I would have wanted the most on Retrospring before the project stopped was, of course, RSS feeds. I thus made my own ask box system using the usual combination of an RSS feed and an XSLT.

You can send questions through anything on my contact page, but the recommended way is through the old-school mailto HTML form provided by the XSLT that helps you email my Naver address through your own email client.

And for the answers previously posted on both Retrospring instances, because I had plenty of time to export them before they disappeared, they are now available as separate archive feed.

Feel free to send me questions about anything, not necessarily RSS-specific things. But if you do send me something syndication-related, maybe I will end up replying to it here instead of on the ask box.

But thanks to this warning, I also found out that tilde.town has a blog! It has articles from years ago, but for some reason I had never found it before. And it has an RSS feed of course. So I am featuring this now as a way to perhaps warn anyone who relies on some of the things I have on tilde.town, for example ITSB or the askbox, that those will probably be unavailable this Saturday and Sunday.

The town is being moved from DigitalOcean towards a new server in a colo hosted by ~insom, a nice townie that I previously featured here. This new pink server will run Debian testing, while we currently have Ubuntu 22.04, so maybe this will break some of my scripts. I often have to rewrite most of my configurations, tools and scripts to adapt to Ubuntu specifically, so we'll see if I have to do this again with Debian or if they are doing better than Ubuntu.

RSRSSS and my wiki will not be affected, since they are hosted on envs.net. That project does need some financial support though!

And just as I finish writing this post, I get a little broadcast message in my shell. I would have likely missed it if that had been my only warning, since it's late enough that I should normally be asleep.

Broadcast message from root@tilde.town (pts/114) (Fri May 23 22:45:47 2025):

LISTEN UP!

the town is moving to a new home.

this means a weekend of downtime starting TOMORROW MORNING (the 24th of May)

if you have any urgent town business...see to it soon!

otherwise look forward to a RAGNAROK CELEBRATION tomorrow morning.

CHECK BBJ FOR MORE INFO ON ALL THIS