--- title: "FDML? Here's a different direction" url: "https://osherove.com/blog/2003/10/15/fdml-heres-a-different-direction.md" canonical: "https://osherove.com/blog/2003/10/15/fdml-heres-a-different-direction.html" published: "2003-10-15T00:16:00" updated: "2003-10-15T00:16:00" tags: ["Blogging"] author: "Roy Osherove" description: "I’m not much in the way of thinking about various RSS standards, XML schemas and so on, so usually all the stuff that Sam Ruby writes about those matters gets blurred to me real fast. Maybe it’s because I’ve been so…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # FDML? Here's a different direction By Roy Osherove October 15, 2003 In [Blogging](https://osherove.com/blog/category/blogging) **Historical article** · Originally published October 15, 2003; technical details may be outdated. I’m not much in the way of thinking about various RSS standards, XML schemas and so on, so usually all the stuff that [Sam Ruby](http://www.intertwingly.net/blog/) writes about those matters gets blurred to me real fast. Maybe it’s because I’ve been so caught up with [Feedable](http://royo.is-a-geek.com/sitefeeder/) and trying to find new and exciting ways to scrape a site’s contents, but [one of his latest posts](http://www.intertwingly.net/blog/1611.html) struck a chord with me. A chord which says “Hey, I have an idea and it’s time someone laughed at it!”. So here I am, preparing to write this down. So basically, what Sam talks about in there is how he and some of the guys were thinking about providing some sort of a “**F**eed **D**iscovery **M**arkup **L**anguage” (FDML? Ugh –sounds awful but what do I know?) for sites that wish to be able to describe their various syndication channels (RSS feeds for now..). I wanted to take a look at it from a different angle. **Let’s turn this whole thing around**. Looking at the subject matter from afar, we can see that we basically have several basic “entities” in this space: ·         **Data Provider**: The site/ organization that would like to expose data to the outside world. ·         **Data**: This is the data that the site wants to expose. Currently it is represented as HTML. ·         **View**: This is a view of the data. A browser provides a view of the provider’s data. An RSS aggregator is yet another view of that same data. Now, you could say that HTML is a sort of a “view” on the data, and that RSS is a different view on that data. What Sam is saying is “Let’s create a method for describing the RSS view that the provider exposes”. Looking at [how Feedable works](http://weblogs.asp.net/rosherove/posts/29509.aspx): \-         [Feedable](http://royo.is-a-geek.com/sitefeeder/) treats the site’s HTML – one of the view, as actual data. \-         It looks at the “data” with one simple variable in place – a regular expression that describes how to extract a different “view” from that ‘data’. \-         It then creates that new view using that description, and what we get at the end is: \-         HTML is a “data” with two unique “views” on it: the HTML itself, and the RSS feed that was generated from it.. Notice that in no time, is there a need for the site to generate yet another “view” of it’s underlying data. No RSS feed is created. In fact, the task of creating an RSS feed is left solely to the **client**\- [Feedable](http://royo.is-a-geek.com/sitefeeder/) site. So, what **would** happen if we decided the following? ·         Instead of generating an RSS feed, each site would actually generate a small, static description file o        The file will hold the necessary regular expression that is required to parse it’s “**contents page**” §         The file (regular expression) will expose a know set of “fields” and how to “scrape” them from that page. Possible fields: “_Date, data, title_..” and so on. Mainly based on what an RSS feed will show now. Consider that comments can also be described – but I think it might get a little complicated at this stage, and I’ll admit I hadn’t thought much past the first stage. §         The file will also expose the address of the page which is needed for scraping §         The file will be the only source that a reader will need in order to start getting that information o        The contents page will be the page on the site that holds the relevant material that the site wants to expose both as HTML and as **any other protocol** o        **Each aggregator will be responsible for generating the RSS feed given the site’s data description file** o        In fact – if we know how to get the raw data – RSS is only one option. We can easily transform this raw data into anything else. **pros:** \-         A site will only have to create a small description file(low expenses and investment), and rely on clients to be able to parse its data correctly according to the rules specified in that file. \-         Protocol independent; We don’t need to know RSS, XML or what not to get the information we need. We get it raw using regular expressions on simple downloaded text. The [KISS](http://whatis.techtarget.com/definition/0,,sid9_gci521694,00.html) principle at work. \-         That description file can grow to include whatever information we need – such as multiple data sources and so on. **Cons** \-         Describing comments, or anything that is “not right there” might be difficult. But there may be some elegant solution to this that I just can’t think of at 4.06AM. \-         You are limited to what’s in your HTML. \-         If your HTML “patterns” change – so must the regular expression. Considering various CSS styles and dynamic html, this might be a problem, but like everything else with standards, it relies on things being done “a certain way” to work. \-         You are coupled to one view of your data. This is a bit of a rehash of the previous point, but I think it shows just how “breakage” of object oriented rules this is. RSS can be made as just another “view” on data, and a “view” should not depend on other views. That is exactly the case here. I’m not sure just how viable this whole idea is, but it certainly works for [Feedable](http://royo.is-a-geek.com/sitefeeder/). As such, I’d like to throw it “out there”, so that it can at least stimulate some sort of discussion. Consider it a “brain stormer” idea; Not necessarily viable, but it gets your mind going in different directions. ## More in Blogging [All posts in Blogging](https://osherove.com/blog/category/blogging) - Oct 26, 2003 ### [Peter and Douglas do it right (PDC Blogging the way I like it) and the list grows](https://osherove.com/blog/2003/10/26/peter-and-douglas-do-it-right-pdc-blogging-the-way-i-like-it.html) - Oct 26, 2003 ### [Leaving for PDC post hailstorm](https://osherove.com/blog/2003/10/26/leaving-for-pdc-post-hailstorm.html) - Oct 13, 2003 ### [Better times ahead?](https://osherove.com/blog/2003/10/13/better-times-ahead.html) - Oct 13, 2003 ### [More Feedable updates](https://osherove.com/blog/2003/10/13/more-feedable-updates.html) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/