This also works around a problem I noticed in the JoyOfTech feed https://www.joyoftech.com/joyoftech/jotblog/atom.xml
caused by <item> tag mismatches.

However, this led me to realize that the split of XML feed parsing into multiple classes we did in c41991e also made the parser less tolerant to ill-formed feeds: when the feed structure confuses Atom tags and RSS tags (for instance using <description> instead of <content> or vice-versa), the former version was able to retrieve informations, while the current one will not.

I much prefer the prior behavior.

However, this led me to realize that the split of XML feed parsing into multiple classes we did in c41991e also made the parser less tolerant to ill-formed feeds: when the feed structure confuses Atom tags and RSS tags (for instance using <description> instead of <content> or vice-versa), the former version was able to retrieve informations, while the current one will not.

I don't recall that there was mixed parsing. The prior RichXMLParser class had separate code paths depending on the root element. That is why I chose to split the class into multiple classes in the first place. The actual parsing code didn't change.

I would also not be in favour of mixing the parsing code. It leads to more complexity for what presumably is a rare problem. I am sympathetic to having a lenient parser, but there should be limits to this. Parsing known elements from other feed types is a bit too much, in my opinion.

Added more flexibility in each parser