[HN Gopher] Atom feed format was born 20 years ago
___________________________________________________________________
Atom feed format was born 20 years ago
Author : mrzool
Score : 242 points
Date : 2023-06-30 08:44 UTC (14 hours ago)
(HTM) web link (www.rssboard.org)
(TXT) w3m dump (www.rssboard.org)
| zokier wrote:
| Does ActivityPub these days replace the traditional RSS/Atom
| feeds? Feels like it would be the natural successor. Is there
| anything missing besides people publishing and consuming?
| kevincox wrote:
| IMHO no. I thought about this as I run a feed-reader and it
| would be cool to support ActivityPub as a feed protocol.
|
| The main issue is that subscribing shows up on follower lists.
| Maybe for individual users this is fine but as I ran a service
| I didn't want to do this. I ended up with a number of reasons
| why ActivityPub push wouldn't work well.
|
| 1. I didn't want to appear to be advertising the service with a
| generic account subscribed to many feeds.
|
| 2. I didn't want a generic account to provide access to
| "followers only" toots to unintended users. To properly allow
| access approval I would need to put some subscriber info into
| the account. It would also be important to make sure that this
| can't be used as a form of spam (for example if I allowed them
| to put whatever name/message they wanted).
|
| 3. I didn't want to reveal who was subscribed to what.
|
| 4. I didn't want to have dozens of different accounts
| subscribed to popular feeds.
|
| 5. If the user also wants to comment on a post themselves they
| will need a separate account.
|
| You can still poll a user's outbox like any other feed, but now
| you are back to an equivalent to Atom/RSS with no WebSub
| support. (I mean you could use WebSub, it works for any URL but
| no one does, and why would you when you already have
| ActivityPub for push?). So it seems that the anonymity of the
| older feed formats can be useful in some scenarios.
|
| So in the end if I was just going to poll as any other feed
| format, and most services that support ActivityPub also have
| other feeds there was really no point to doing this. Feature
| requests welcome if there is a use case that I missed.
| matsimitsu wrote:
| I'm in the same boat, and came to the same conclusion.
|
| One more point I'd add:
|
| 6. Not every ActivityPub enabled service allows for
| federation. (Some of the more popular block all federation,
| unless you get allowlisted). So you're stuck polling the
| outbox regardless.
| cxr wrote:
| > So it seems that the anonymity of the older feed formats
| can be useful in some scenarios.
|
| Huge understatement; it's more than just "some". None of the
| blogs in my feed reader are written by people that I have a
| public (reified) follower/followee connection with over
| social media. Nor do I have that kind of relationship with
| the authors of the books I check out from the library, for
| that matter.
| rakoo wrote:
| > Is there anything missing
|
| Simplicity. Atom/RSS can perfectly be a static file (it doesn't
| even need internet connectivity, an Atom file can be passed
| around on a usb key with 100% of functionality). ActivityPub
| requires a live server with computation. Think about the step
| it requires for every website and every account and every
| service to have an atom feed vs an activitypub actor.
| miki123211 wrote:
| ActivityPub, despite using JSON rather than XML, is a much more
| complex protocol with a lot more moving parts. You can
| technically write an RSS feed by hand, drop it on a virtual
| hosting provider via FTP, and you have a feed. On the server
| side, all you need is static file hosting, which is ubiquitous,
| available for free and amenable to things like CDNs. On the
| client side, all you need is a single device, which may be
| behind NAT, and is capable of occasional network connections to
| pull the updated feeds.
|
| With ActivityPub, you're supposed to have an account at an
| instance and receive content through that instance. This means
| that the server needs to keep track of followers and
| automatically broadcast all new content to all of them, which
| requires a database, some kind of content-publishing API, and
| probably a job queue and Redis to boot. On the client side, you
| need a box that is online 24/7 and can be connected to, so that
| you can receive your content. You get much faster delivery, but
| at a much higher operational costs and with many more
| scalability issues. Hosting static content at scale is a solved
| problem, and you can reuse all that existing knowledge for RSS.
| Sending AP activities at scale is technically solvable, but the
| infrastructure just isn't there yet.
| lapcat wrote:
| > Does ActivityPub these days replace the traditional RSS/Atom
| feeds?
|
| No. In fact, Mastodon has RSS feed support.
|
| Downloading an XML file is dead simple. ActivityPub is vastly
| more complex.
| unshavedyak wrote:
| I'm writing some ActivityPub stuff, and wanted to make sure
| to get RSS in, done right, etc. However i never use RSS so i
| have little insight to good/bad/irrelevant RSS impls.
|
| Any wants or must-haves to an RSS implementation over a
| Fediverse instance?
|
| My rough plan is to just include RSS in any places i expose
| JSON endpoints for data. Though i'm a bit undecided if
| there's any value in user activity stuff, like comments on an
| article, etc.
| goffi wrote:
| XMPP does use Atom as its (micro)blogging format (XEP-0277),
| and making followers/following lists (subscribers/subscribed in
| XMPP terms) public is opt-in with XEP-0465.
|
| Note: I'm very involved in XMPP, and the author of the latter
| XEP.
|
| Edit: forgot to mention that it's also available to ActivityPub
| thanks to the XMPP <=> AP gateway (that I've authored too)
| tbyehl wrote:
| I need an "I Survived the Syndication Format Wars" t-shirt.
| olzhas wrote:
| Initially, my thought was "wow, that thing was invented in 80s".
| jzawodn wrote:
| Sigh. That happens to me too.
| ilyt wrote:
| still dunno what's the difference between rss1.0, 2.0 and atom
| benoliver999 wrote:
| I pick one at random, paste it into my feed reader, the feeds
| appear, hey presto!
| x2rj wrote:
| Atom is an order of magnitude more complex and strict standard
| by people who really love xml in contrast to the really simple
| and less strict rss 2.0. For example almost everything is
| optional in rss 2.0 so you can have a reasonable feed for stuff
| like tweets or linkblogs where there is no obvious title. In
| contrast atom enforces a title for every item which makes this
| a messy expirience.
|
| I have implemented rss 2.0 parser faster then understanding the
| atom specification. Atom can do encode stuff like encode html
| inline the xml instead of as a CDATA string. In theory this
| sounds great, but is ends up in a big mess of complexity (e.g.
| a blogpost with handwritten invalid html).
|
| These days there is also JSONFeed which is really easy to
| parse, simple and flexible, but it is not supported everywhere
| yet.
| simonw wrote:
| The RSS 2.0 spec has a horrible flaw:
|
| https://www.rssboard.org/rss-2-0-1-rv-6#hrelementsOfLtitemgt
|
| > An item may also be complete in itself, if so, the
| description contains the text (entity-encoded HTML is
| allowed; see examples)
|
| Note "is allowed", not "is required". This caused SO MANY
| problems back in the day, because the spec didn't clarify if
| you should or should not include HTML in that element - and
| there was no way of telling, when parsing a feed, if the
| author was in the "entity-encoded HTML" or "YOLO and just
| stick plain text in there" camp.
|
| IIRC, Atom came about precisely because the RSS
| specifications didn't provide the level of detail needed for
| a spec to be truly interoperable.
| eduction wrote:
| In practice, the description is universally considered to
| be html encoded. Everything is decoded. If you try to stick
| unencoded html in there it gets rendered as text. If you
| really don't want to encode you can stick it in CDATA and
| it will just work per the xml spec. I'm trying to remember
| what the downside of this approach is - I think maybe it
| kept people from sticking unencoded ampersands in plain
| text or something.
|
| But I think it's worth noting that a cultural tradition
| emerged that papered over the flawed spec. I think that is
| actually pretty common with specs, even if the rss2 one is
| extra loose.
|
| Maybe having a correct spec isn't everything.
| ttepasse wrote:
| > But I think it's worth noting that a cultural tradition
| emerged that papered over the flawed spec.
|
| Back in 2013 a developer of a feed crawler wrote a
| selection of things people get wrong with their feeds.
|
| https://inessential.com/2013/03/18/brians_stupid_feed_tri
| cks
| eduction wrote:
| This is definitely a good example of "RSS culture."
|
| (This particular one isn't papering over flaws in the
| spec, many of thse are advising against doing things that
| violate either RSS or XML spec, or are subjective
| opinions additive to the spec (e.g. always have a
| datetime). But ya this is basically what I mean.)
| ttepasse wrote:
| > I have implemented rss 2.0 parser faster then understanding
| the atom specification. Atom can do encode stuff like encode
| html inline the xml instead of as a CDATA string. In theory
| this sounds great, but is ends up in a big mess of complexity
| (e.g. a blogpost with handwritten invalid html).
|
| The same thing can also happen in RSS feeds (and JSON Feeds):
| Entity-encoded HTML strings or CDATA HTML strings do not have
| any guarantee of well-formed-ness. The direct embedding of
| XHTML into Atom as namespaced elements just surfaces
| potential invalid markup higher up.
| CharlesW wrote:
| > _The same thing can also happen in RSS feeds [...]:
| Entity-encoded HTML strings or CDATA HTML strings do not
| have any guarantee of well-formed-ness._
|
| I wrote a podcast validator, and I don't think that's true
| -- every RSS feed must be "well-formed" XML.
|
| (Note that all "valid" XML documents are "well-formed", but
| "well-formed" XML documents are not necessarily "valid".)
| ttepasse wrote:
| I was talking about the (X)HTML in that RSS feed and its
| well-formed-ness.
|
| In a perfect world people would construct their XML
| documents with an API which guarantees that the generated
| serialisation is a well-formed XML document. E.g. the API
| guarantees that the element tree is nested, that
| namespaces are declared and that the serialiser escapes
| any text nodes. Then people could add their well-formed
| XHTML fragments as a child to <atom:content type="xhtml">
| and then serialise the whole document, guaranteeing well-
| formed-ness across namespaces.
|
| In practice people have a tagsoup string from their data
| store which they concatenate inside their RSS template in
| <description>. If you're lucky, they replace "<" and "&"
| beforehand or do the CDATA thing. But in XML terms that
| is just a string, not well-formed markup.
| CharlesW wrote:
| Interesting, thank you. Every podcast RSS feed (a tiny
| subset of RSS feeds) I've seen in the wild is well-formed
| in the strict XML sense, so the tagsoup problem must be
| more endemic on the text syndication side.
| ttepasse wrote:
| I can imagine that that is potentially a result of
| Apple's dominant podcast directory. Podcasters submit
| their feeds to Apple's Podcast Connect, which I think
| flags warnings and errors. Other forms of feed don't have
| that big motivation to validate.
| [deleted]
| gerikson wrote:
| Please read this comment that summarizes the situation:
|
| https://news.ycombinator.com/item?id=36378817
| masklinn wrote:
| The TLDR is RSS is messy shit while Atom is well specified and
| works for anything you need outside of podcasts.
|
| As long as you don't need to _consume_ feeds, just use atom.
|
| The less TL is that RSS1 and RSS2 are basically two different
| branches of the original:
|
| - Netscape released RSS 0.90 as an RDF application (RSS
| literally stood for RDF Site Summary) - RSS 1.0 was an update /
| direct evolution of RSS 0.90 by a dedicated working group using
| final RDF 1.0 semantics (as RSS 0.90 had been based on an
| earlier working draft) - RSS 1.1 an evolution of RSS 1.0 by
| unrelated people
|
| This is called the RDF branch, for obvious reasons.
|
| However a few months after RSS 0.90 Netscape also released RSS
| 0.91, which dropped RDF entirely, rebranded to "Really Simple
| Syndication", and added some elements from Userland's own
| syndication format.
|
| This is the start of the "Harvard" (formerly "Userland")
| branch, Userland / Dave Winer released his own variant of 0.91
| (timeline with netscape has never been super clear to me), then
| went on to release 0.92 with an <enclosure> element, followed
| by 0.93 and 0.94. He then released RSS 2.0 to mark a bit of a
| compatibility break, as RSS 2.0 adds namespace support and
| removes some elements from his 0.9, and also to fuck with the
| RSS WG's 1.0 release.
|
| Because the Harvard branch was the first to support enclosures
| (embedding audio) and Userland had built support for that, it
| became the de-facto format for podcast feeds, Atom also
| supports enclosures but I'm not sure any podcast client (or
| podcasting source) supports them.
| pferde wrote:
| While RSS is, as you say, quite messy, Atom has also brought
| lots of headaches to this poor feed aggregator developer over
| the years. Its specification is a lot tighter than RSS', but
| there is still enough wiggle room for feed generators to get
| creative and make you want to strangle somebody.
| throw0101c wrote:
| Perhaps time for RFC4287bis to tighten up the grey areas?
|
| Are there specific things that come to mind as specifically
| annoying?
| pferde wrote:
| It's been a long time since I spent my time on that, so I
| do not remember anything specific. But it was difficult
| figuring out reliably if a post in a given feed matched
| an already existing (locally cached) post, whether it was
| an updated version of that post, or whether if it was a
| completely new, hitherto unseen post, so it had something
| to do with the post IDs, timestamps and URLs.
| jgalt212 wrote:
| sounds like Postel's law in play, but I agree it's annoying
| that there are incorrect / bad atom emitters.
|
| https://ardalis.com/postels-law-robustness-principle/
| ttepasse wrote:
| I believe iTunes/Podcasts since its beginning also supported
| Atom podcasts until they deprecated it some years ago. But I
| believe they were some of the very few.
| outsidetheparty wrote:
| My strong impression at the time was that the primary impetus for
| establishing Atom was that Dave Winer was abrasive and
| opinionated, and some people just didn't like him very much.
| CharlesW wrote:
| That seems extremely petty if true.
|
| FWIW,
| https://en.wikipedia.org/wiki/History_of_web_syndication_tec...
| notes that Atom was a side-effect of RSS being frozen. Also
| FWIW, Dave gave Atom (then Echo) a tentative early endorsement:
|
| _" If and when it reaches closure, I will recommend to
| UserLand that they support the format, both for input and
| output, and I will help to the extent I can to write drivers
| for the software. I will continue to answer questions for the
| people working on Echo, and offer my opinion when it appears to
| be welcome, but will step back when it is not."_ --
| http://backend.userland.com/2003/06/26
|
| And, true to his word, Dave added support for Atom in UserLand
| products in 2007.
| spc476 wrote:
| Mainly, it was Dave not bothering to clarify how to include
| HTML in the RSS feed, instead saying, "the spec is the spec
| and it's not changing!"
| CharlesW wrote:
| IIRC that's always been supported via CDATA.
| xefer wrote:
| There is the Atom Feed Format and there is the Atom Syndication
| Protocol:
| https://datatracker.ietf.org/doc/html/rfc4287
| https://datatracker.ietf.org/doc/html/rfc5023
|
| These specs and the discussion about them at the time really are
| from a different era of the web. The Syndication Protocol fully
| embraced REST which was also white hot then. There was a real
| feeling that with a good format and a standardized way to consume
| and interact with the resources, it would allow for easier
| sharing of not just blog posts but other data as well.
|
| As intense as the discussion was around the development of
| RFC-5023, it was basically ignored from the moment it was
| released and even the main spec author declared it basically dead
| not very long afterward:
|
| https://web.archive.org/web/20090421042741/http://bitworking...
|
| Needless to say, the web took an entirely different direction and
| while these specs exist, there isn't much interest in them any
| longer.
| ttepasse wrote:
| There are also some extensions for richer data models and
| working with changing feeds:
|
| RFC 4685: Atom Threading Extensions
|
| https://www.rfc-editor.org/rfc/rfc4685.html
|
| RFC 4946: Atom License Extension
|
| https://www.rfc-editor.org/rfc/rfc4946.html
|
| RFC 5005: Feed Paging and Archiving
|
| https://www.rfc-editor.org/rfc/rfc5005.html
|
| RFC 6721: The Atom "deleted-entry" Element
|
| https://www.rfc-editor.org/rfc/rfc6721.html
|
| There were more stuff thought of, as far as I recall, and I
| bookmarked a lot of them. But on Delicious. Somewhere in some
| backup there must be my archive.
| msla wrote:
| https://datatracker.ietf.org/doc/html/rfc4287
|
| https://datatracker.ietf.org/doc/html/rfc5023
| yanis_t wrote:
| In case anyone is looking for a free rss reader for mobile here's
| the one I built for myself after Feedly became unbearably slow
| https://www.justfeed.io/
| robobro wrote:
| Whenever I need to provide a feed, I always choose Atom because
| (a) the spec is better and (b) anything that can handle RSS will
| generally also handle Atom.
| varjag wrote:
| If there's one thing am most grateful to millennials for, it's
| killing XML.
| hfkwer wrote:
| In what format do you think the website you're reading is
| written in? Sure html is not 100% super duper pure xml, but for
| all intents and purposes, it's xml.
| varjag wrote:
| Sure sure. XML is dead but its tradition of piggybacking on
| HTML success lives as I see.
| lapcat wrote:
| I prefer Atom to RSS.
|
| 1) Atom has separate <updated> and <published> fields, while RSS
| just has <pubDate>. Moreover, RSS wants to you add a redundant
| day of the week in the date, i.e., "Sat, 07 Sep 2002 0:00:01
| GMT", which is dumb.
|
| 2) Atom allows you to use <content
| type="html"><![CDATA[]]></content> where you can just stick in
| HTML, whereas RSS <description> just specifies "entity-encoded
| HTML is allowed".
|
| 3) RSS has redundant <guid isPermaLink="true"> vs. <link>. Which
| one is a feed reader supposed to use?
| Hamuko wrote:
| As a consumer, I don't really have any preference. Both work
| fine with my software. My personal blog uses Atom only because
| my static site generator had an Atom plugin.
| eloisant wrote:
| Atom is slightly better than RSS, but didn't brought enough
| improvements to kill RSS.
| justinator wrote:
| But enough where my app supports both and will support both
| for the remainder of time!
| mort96 wrote:
| And enough to bifurcate the community by having two
| conflicting standards!
| asdff wrote:
| Is it really bifurcated for the end user though? Its the
| same tooling to view both feeds. The same workflow to add
| either feed to your feed reader. You don't even realize
| whether its an atom or rss feed unless you start looking
| into it.
| mort96 wrote:
| It's certainly a bifurcation for feed authors.
| Macha wrote:
| Just pick your favourite and supply that? If all consumer
| software supports both formats, why do you need to
| provide both?
| ulrischa wrote:
| Why is the name Atom?
| rcade wrote:
| I think the inspiration was that an atom is a foundational
| building block of matter and a lot of things could be built
| with a well-specified universal feed format and publishing
| format.
|
| The time spent debating names, disqualifying names,
| requalifying names and voting on names was like the battle of
| the newscasters on Anchorman. Pure carnage.
| bullen wrote:
| For my blog tool I made feeds in 3 flavours; RSS, Atom and my
| own:
|
| http://sprout.rupy.se/feed?rss
|
| http://sprout.rupy.se/feed?atom
|
| http://sprout.rupy.se/feed
|
| Now that I look at them they are equally bad.
|
| That said ActivityPub with JSON does not strike me as better.
|
| Seriously considering getting into the fray...
| ttepasse wrote:
| If you want to expand even more, there are even more options:
|
| * RSS 1.0 - the RDF/XML serialisation.
|
| * JSON Feed
|
| * h-feed/hAtom - embedding the "feed" as Microformats markup
| inside the HTML.
|
| * schema.org/Blog - embedding the "feed" inside the HTML,
| either with RDFa or with JSON-LD or with Microdata.
|
| * If you want to annoy the most people at once, there is a
| great solution: The data model from RSS 1.0 is of course RDF-
| based. The modern serialisation of RDF is JSON-LD - simply use
| the RSS 1.0 vocabulary in a "JSON-LD-Feed".
| robobro wrote:
| It's interesting you made your own feed format, but... why?
| Does anything actually support it?
|
| May be worth making a jsonfeed while you're at it, if you just
| want to make more options.
| bullen wrote:
| I wanted something simpler and was just playing around.
|
| JSON I use in my distributed DB (http://root.rupy.se), it's
| less verbose but XML to me is also a development tool that
| gains with human readability.
|
| The bottleneck is almost never bandwidth on small solutions.
|
| What I'm considering now is making my own ActivityPub, adding
| Reddit like features and Email.
|
| I would like to make the format pipe (|) separated instead of
| XML/JSON...
|
| The social protocol to end all social protocols. XD
| ttepasse wrote:
| Prior art:
|
| http://www.aaronsw.com/weblog/000574
|
| http://www.aaronsw.com/2002/rss30
|
| https://web.archive.org/web/20051025234617/http://www.synta
| x...
| eduction wrote:
| Atom vs RSS is a great example of how technical correctness is
| trumped by social factors, in this case namely support from
| makers of popular software and content as well as social
| influence and documentation skills of creators.
|
| The person who pushed RSS to success (IMO) Dave Winer was superb
| at communicating and evangelizing his goals, connecting partners
| like Netscape and NYT, and documenting his work including the RSS
| related tools he built.
|
| His spec was "worse" in the sense that it was under specified but
| better in the sense that it achieved wide support (both in text
| and podcast form) among people who made content. This is partly
| because Dave had first an influential email newsletter and Wired
| column (DaveNet) and second an influential very early blog
| Scripting News. He had also been working with news companies for
| years at prior startups. He could write well. He showed up for
| and arranged meetings with people who did not at first understand
| the need for something like rss. He was clear and relentless in
| his promotion which was borne out of what seemed to be a genuine
| desire for open standards in this area rather than greed / trying
| to do lock in.
|
| People with technical backgrounds in places like this tend to
| fixate on the technical aspects of Atom vs RSS. There is no
| question Atom is more technically correct. There is also no
| question (IMO) it came too late and focused on the wrong things
| -- being correct and complete at the expense of being complicated
| and hard to understand -- and more importantly was led and
| promoted by people who lacked the social skills to make it
| popular outside of technical circles. (These folks could be
| brutal about rss's flaws without seeming to have awareness of
| this shortcoming in their own effort.)
| treve wrote:
| Almost any reader and platform supports both so I don't even
| know why the discussion is relevant.
|
| If you have a preference, use it and feed readers will likely
| just work.
| thaumasiotes wrote:
| > Atom vs RSS is a great example of how technical correctness
| is trumped by social factors
|
| I don't follow. Out there in the world, RSS feeds provide their
| feeds in Atom format. The technical format is called "Atom" and
| the functionality that the Atom format implements is called
| "RSS".
|
| In what sense did technically-correct Atom get trumped by
| anything? This is like complaining that social factors caused
| "the SAT" to get trumped by "standardized testing".
| majormajor wrote:
| > Out there in the world, RSS feeds provide their feeds in
| Atom format.
|
| I just checked a few of the ones I follow, and ... turns out
| I don't immediately know how to distinguish when there's not
| a specific xml namespace reference in the doc or such.
|
| But according to Wikipedia the RFC822 timestamps I'm seeing
| suggest they're RSS2 instead of Atom?
| re wrote:
| > turns out I don't immediately know how to distinguish
|
| Atom feeds will almost always have <feed
| xmlns="http://www.w3.org/2005/Atom"> as the root element.
| In some cases they may use namespace prefixes but that
| tends to be rarer and less interoperable.
|
| RSS feeds have an <rss version="2.0"> root element.
| majormajor wrote:
| In that case the four I spot checked were all RSS, I
| guess. Though some of them had other references to atom
| things within them.
| eloisant wrote:
| RSS and Atom are 2 different formats.
|
| Your confusion probably comes from the fact that RSS is
| older, so it's sometimes used as the name of the
| functionality but it's improper. They're 2 different formats.
| thaumasiotes wrote:
| So what? That has nothing to do with my comment.
|
| There are feed formats named "RSS". There is a feed format
| named "Atom". And there is a concept named "RSS". The RSS
| formats, like the Atom format, are all implementations of
| the RSS concept. Generally, when you subscribe to an RSS
| feed somewhere, it will be in the Atom format. It's still
| called an "RSS feed" for the simple reason that that is the
| name of the concept.
|
| > it's sometimes used as the name of the functionality but
| it's improper.
|
| No it isn't. What would you gain by insisting that RSS
| feeds delivered via Atom have to be called something
| different than RSS feeds delivered in legacy formats? Did
| we rename TLS when we updated the cipher suites?
|
| Why, in your opinion, is rssboard.org _even bothering to
| write about_ Atom?
| throw0101c wrote:
| > _And there is a concept named "RSS"._
|
| The concept is called a (web/news) feed:
|
| * https://en.wikipedia.org/wiki/Web_feed
|
| > _It 's still called an "RSS feed" for the simple reason
| that that is the name of the concept._
|
| No, it's because "RSS" is acting as an adjective to the
| noun of "feed". See also "Atom feed": Atom being the
| adjective, feed being the noun (concept).
|
| > _RSS (RDF Site Summary or Really Simple Syndication)[2]
| is a web feed[3] that_ [...]
|
| * https://en.wikipedia.org/wiki/RSS
| rcade wrote:
| I wouldn't say that an Atom feed is an implementation of
| the "RSS concept." That muddies the water too much.
| Because RSS and Atom are distinct feed formats, calling
| an Atom feed "RSS" would confuse a lot of people.
|
| Instead I'd say that Atom feeds and RSS feeds are each an
| implementation of the syndication concept.
| throw0101c wrote:
| > _Atom vs RSS is a great example of how technical correctness
| is trumped by social factors_
|
| Or perhaps having at six year head start (RSS 0.90, 1999; Atom,
| 2005) and having it compound.
|
| This includes podcasting, as the term was coined in 2004, but
| which was happening even before that (and before Atom was
| finalized):
|
| * https://en.wikipedia.org/wiki/Podcast#Etymology
|
| First mover advantage, leading to network effects, can be a
| thing.
| samstave wrote:
| So is this as BetaMax was to VHS?
|
| EDIT on 'podcast':
|
| I was literally wondering this AM where 'pod'cast came from -
| thank you for the link (I love in-sects, which is why I love
| Etymology!)
| westurner wrote:
| RSS > RSS compared with Atom
| https://en.wikipedia.org/wiki/RSS#RSS_compared_with_Atom
|
| CDATA > CDATA in XML:
| https://en.m.wikipedia.org/wiki/CDATA#CDATA_sections_in_XML
|
| IIRC RSS was not originally an XML document, so CDATA tags
| (to prevent XSS) didn't work; and the issue remains with
| content syndication: feed elements should somehow HTML escape
| their content to prevent XSS (arbitrary JS on a different
| Origin)
|
| XSS: Cross-site Scripting:
| https://en.wikipedia.org/wiki/Cross-site_scripting
|
| Same-origin policy: https://en.wikipedia.org/wiki/Same-
| origin_policy https://developer.mozilla.org/en-
| US/docs/Web/Security/Same-o...
|
| Content Security Policy (CSP)
| https://en.wikipedia.org/wiki/Content_Security_Policy
| https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
|
| CSRF: Cross-site request forgery:
| https://en.wikipedia.org/wiki/Cross-site_request_forgery
|
| JSONP > CSRF: https://en.wikipedia.org/wiki/JSONP#Cross-
| site_request_forge...
|
| The whole internet was broken, and RSS helped us realize it:
| the one-way, one-time syndication advantage.
|
| These days it's all about https://schema.org/CreativeWork
| JSON-LD instead of RDFa, which you can try to sanitize with
| Mozilla/bleach like arbitrary HTML in comments on the page.
| CharlesW wrote:
| > _IIRC RSS was not originally an XML document..._
|
| AFAIK RDF Site Summary (the original meaning of "RSS") used
| XML from the start1. You may be thinking of spiritual
| predecessors like the Apple-developed MCF2.
|
| 1 https://www.rssboard.org/rss-0-9-0 2 https://en.wikipedia
| .org/wiki/History_of_web_syndication_tec...
| PaulHoule wrote:
| It really amused me that people think "RDF never caught
| on" when it is the basis of so many major standards such
| as RSS, Adobe's XMP metadata, and, I just found out,
| ActivityPub.
|
| I was working on a standards committee for years and made
| the discovery that you can turn most XML Schema
| Definitions into an OWL ontologies and thus automatically
| transform conforming XML documents into RDF documents.
|
| (People had attempted this before but all the systems I
| saw were lossy or didn't make valid and decidable
| ontologies.)
|
| For better and worse my write up[ is about to become one
| of those ISO standard documents that costs 166 swiss
| franc but it looks like I'll get the opportunity to apply
| this method to a major financial standard and release the
| software that does it as open source.
|
| I'd contrast that to the truly awful RDF/XML spec where
| people never really understood where the XML stopped and
| the RDF began. It turned a lot of people off to RDF and
| people never got to see how easy it is with Turtle.
| Unfortunately JSON-LD hasn't got the love it deserves
| because it fixes most of the major problems with JSONs
| except for the lack of /* comments */ and you can
| frequently add a touch of JSON-LD to a JSON document you
| find on the street and get instant RDF you can query w/
| SPARQL.
|
| It looks like the W3C has started the process of a SPARQL
| 1.2 spec which could be a very good thing if it catches
| up with what is possible w/ document database query
| languages like N1QL, AQL and such.
| [deleted]
| acdha wrote:
| I'd also add Google dropping reader and trying to force open
| web content into various proprietary schemes. Atom's many
| improvements over RSS didn't matter as much when the oxygen
| was getting sucked out of the room and few people were
| investing more time in feeds.
| SCAQTony wrote:
| Well, the FTC is about to crack down on fake 5-star reviews
| levying 50k fines, perhaps paid fake endorsements are next?
|
| https://www.washingtonpost.com/technology/2023/06/30/fake-re...
| SCAQTony wrote:
| I got voted down, perhaps someone paid for that downvote? ;-)
| immibis wrote:
| It has no relevance to the article.
___________________________________________________________________
(page generated 2023-06-30 23:00 UTC)