A significant update of The 'iffy' XML namespace was made on 2024-11-15 @ 01:10 AM EST.
→ Documentiffy:curation, and curation type elementsiffy:all,iffy:recent,iffy:selection,iffy:single.
The post was originally published 2024-05-13 @ 04:10 AM EDT.
This blog now generates single-item RSS alongside each blog post.
This is in preparation for how I mean to support blog-to-blog comments, most directly.
But in general it is offered as an alternative to approaches like microformats.
Microformats exist and other people use them. I feel a bit bad not to adopt them. But my preference is to have meta-data more cleanly separated from displayed HTML, even if it is "POSH". It seems to me like too many concerns are mixed.
If microformats were very widely adopted — particularly if the JVM ecosystem already had well-supported, widely used microformats parsers — I might swallow my own preference and run with them. But I don't think that's the case. I'm going to have to do my own parsing, and I have good tools for that with XML and RSS.
unstatic SimpleBlog instances now support generating single-item RSS. Just override
val generateSingleItemRss : Boolean
to true, and they will appear.
By default, each entry's single-item RSS is placed by converting each whatever.html to whatever.rss, under the same path. (If the leaf of the path does not end with .html, then .rss is simply appended to the full path.)
If you prefer a different scheme, you can override
def singleItemRssSiteRootedFromPermalinkSiteRooted( permalinkSiteRooted : Rooted ) : Rooted
where Rooted is a unstantic.UrlPath.Rooted.
Single-item RSS and the HTML "permalink" for the item should mutually refer to one another.
In the HTML header tag, we add a <link> tag with rel="alternate" to point to the single-item RSS.
We don't want feed readers to subscribe to single-item RSS, so, a bit clumsily, we make up a special content type that feed readers won't recognize, application/x-single-item-rss+xml.
Here's the link you'll find in the source of this post.
<link rel="alternate" type="application/x-single-item-rss+xml" title="Supporting single-item RSS" href="index.rss">
The single-item RSS links back to the HTML as a matter of course, via the standard <link> element within the sole <item>.
Check out the single-item RSS for this post!
Note: If an <atom:link rel="self" /> tag is included in the <channel> element of a single-item RSS stream, the type should be the standard type="application/rss+xml", and definitely not application/x-single-item-rss+xml. (I recommend <atom:link rel="self" /> always be included in the <channel> of an RSS stream, whenever there exists a stable link to the stream.) Single-item RSS is just standard RSS for all purposes other than a feed-reader deciding whether to treat a feed as subscribable.
A significant update of The 'iffy' XML namespace was made on 2024-11-02 @ 05:15 PM EDT.
→ Clarifications of iffy:provenance and iffy:update-history.
The post was originally published 2024-05-13 @ 04:10 AM EDT.
A significant update of Neonix was made on 2024-08-16 @ 11:20 AM EDT.
→ Add update regarding new location of Bill Mill's "modern unix tool list"
The post was originally published 2024-06-06 @ 03:35 PM EDT.
A significant update of The 'iffy' XML namespace was made on 2024-07-01 @ 02:40 PM EDT.
→ Major revision ofiffy:synthetic, generalizeiffy:initial,iffy:update,iffy:update-history, defineiffy:uid.
The post was originally published 2024-05-13 @ 04:10 AM EDT.
In the previous post, I claimed to be "finished" my exploration of handling updates.
Ha!
I don't like how my update notifications appear in digests — in e-mail newsletters that gather up all the posts over a period of time.
There are two problems:
Update notifications appear in digests as separate, cookie-cutter posts, which bury and dilute "real" posts.
On websites, we can make synthetic update posts visually distinct to help guide visitors past them. We could do that in HTML mail digests too, but I think update posts will still put people off actually reading new material when they are going quickly through their e-mail, particularly when updates are more recent and therefore come before the "real" posts.
Updates appear even for posts that are included in the current digest.
feedletter digests always include the most recently seen version of a post, so from the digest reader's perspective, the "update" notification tells them about nothing that isn't already in the post.
To address this, I mean to do a bunch of things.
I'm going to modify the definition of iffy:synthetic, reversing course on my my current admonition that
Applications that include
iffy:syntheticas a direct child of channel SHOULD NOT also mark individualitems asiffy:synthetic, unless there is some meaningful sense in which some items are more synthetic than others. It serves no purpose to mark every item of a feediffy:syntheticwhen the channel is already so marked.
Never mind.
Until now, iffy:synthetic has been basically just a marker, so there was no point in marking posts twice. Marking at the channel level implied the syntheticness and the types at the item level.
But now we'll reconceive of iffy:synthetic as also the carrier of the data on which the item content (in description, content:encoded, or atom:content) is based.
The item content, of course, remains the post's HTML, whether it is a synthetic post or not. But we'll want the information we used to compose synthetic posts to be available, in an iffy:type-dependent way, inside item > iffy:synthetic. So even when a channel is marked synthetic, with a type that implies the type of elements, we will want explicitly to include an iffy:synthetic element in each item.
For synthethic items of type UpdateAnnouncement — the relevant case here — we've already defined an element that carries most the relevant data, iffy:update.
We'll also need the guid of the post updated. So we'll bring back iffy:original-guid, with a slightly modified role.
I'll define a feedletter content Customizer that
items already in the post;So. We have a plan!
Let's see if it works.
A significant update of Sprouted was made on 2024-06-20 @ 05:50 PM EDT.
→ Add bold update crediting Maggie Appleton for some of these ideas.
The post was originally published 2024-06-20 @ 03:05 PM EDT.
I've finally "finished" my reaction to Chris Krycho's provocation, Feeds are Not Fit for Gardening. (ht Erlend Sogge Heggen).
I think I now have infrastructure sufficient to publish evolving content, that might start as an unfinished sketch and "blossom" over time (and with help and interaction from you, dear reader).
The approach I've taken — of course since I am an RSS fanboy — is to graft what I need on top of existing RSS infrastructure. Among RSS infrastructure, I include both conventional feed readers and "announcers": RSS consumers that notify parties about new items in ways that may be more disruptive than just another item in a well-populated feed.
An example on an announcer is my own feedletter, which notifies RSS items by e-mailing posts one at a time or in digests, and also by posting to Mastodon.
My approach is quite manual. No software determines when an "update" has been made. "Tweaks" — which may include correcting typos, reworking sentences, or even rewriting whole paragraphs without changing the intended meaning — shouldn't be notified as updates. Modifications, however big or small, that substantially augment or alter the content of the item usually should be notified. In my view, which is which is the author's judgment call. So authors manually add an item to their post's update history when they wish to provoke such a notification.
Once authors begin to define an update history, that history becomes appended to the end of posts. Example.
When authors declare a meaningful update, all they must provide is a timestamp. An atom:updated element will be included in the RSS item with that timestamp.
Authors also may provide a description, a "revision-spec" (usually a git commit identifier) for the revision superceded, and an author list (if authorship as well as content is changing with the update). Example.
The more authors provide, the richer the update history. Update histories will include any description given, along with links to the prior ("superceded") revision, and a diff between the updated post and the superceded revision.
Whenever a new update is declared, a synthetic post will be produced, whose publication date is the moment of the update, announcing the update. Example.
That post will have its own RSS guid and permalink. So, without requiring any change to the behavior of existing feed readers, followers will be notified of these updates.
The RSS items generated for these updates will be marked "synthetic", of "type" UpdateAnnouncement, so that announcers (for the moment only my feedletter, but please join in!) can decide whether they wish to notify these items.
They include a "hint" for announcers to adopt a Piggyback policy, meaning the synthetic update notifications should be included in digests and other multi-post announcements that include at least one not-piggyback post, but they should not trigger announcements on their own. Announcers are free to follow this hint, or to make a different choice.
For subscribers to notication services that accept the hint, synthetic update posts will not cause people to get spammed with "here's an update!" messages. That would be annoying. On the other hand, e-mail subscribers will not be notified of all updates to existing posts. One-at-a-time subscribers will see none of the update notifications. Digest subscribers will see update notifications only when the digest would also include at least one "organic" post. There is a trade-off to navigate between annoyance and information.
For posts intended to evolve over time, that might invite the attention of particular followers or collaborators, authors can explicitly declare a post to be a "sprout". Example.
The term is taken from Chris Krycho's essay. These posts will be accompanied by their own RSS feeds (example), and will track declared updates only to that particular item. The implementation is not great — ideally each notification would include and highlight the changes — but so far my diffs are too lame for that. However, subscribers will be notified, via a dedicated feed, of each update to evolving items that they mean attentively to follow.
Obviously, nothing is really "finished". Everything in life is a garden!
But I think that this is enough that I can start sketching and evolving posts intended to develop over time, rather than finished-product "atomic" posts.
Thanks to Chris Krycho and Erlend Sogge Heggen for inspiring me to think about all this!
Update: Chris Krycho credits Maggie Appleton for some of these ideas, so I will too!
A significant update of Feedletter tutorial was made on 2024-06-20 @ 01:10 PM EDT.
→ Add note to Section 16, "Advanced: Customize the content" documenting feedletter API changes that slightly modify this section of the tutorial.
The post was originally published 2024-01-29 @ 10:30 AM EST.
A significant update of The 'iffy' XML namespace was made on 2024-06-20 @ 11:05 AM EDT.
→ Documentiffy:type, update documentation ofiffy:syntheticas optionally includingiffy:type.
The post was originally published 2024-05-13 @ 04:10 AM EDT.