XML Format for Recipes, Revisited
Earlier I mentioned an XML Format for Recipes, and only recently I got a comment wondering how that particular format compared with RecipeML.
As far as I can tell, they both derive from a format known as DESSERT, which apparently also came from the same source as RecipeML.
So this would mean that the format at http://www.eatdrinkfeelgood.org is the one that “copied” DESSERT. However, I suspect that what happened was that the original license associated with DESSERT was open enough to allow for derivative works (such as the one at eatdrinkfeelgood.org) and the people at FormatData wanted to enforce more control over the technology, and so when renaming it as RecipeML, they also changed the license to something not as open as the license at EatDrinkFeelGood.org.
So, like lots of things, we now have two competing standards: an open one, and a “proprietary” one, which is more entrenched.
However, if you just search for “xml format for recipes” on Google, you’ll find lots of hits, and some of them are just toy examples. The fact of the matter is, unless you’re a serious dietition or you have LOTS of recipes that you work with (like, you’re writing a cookbook), the benefits to putting your recipes into XML format may not outweight the downsides to investing the time in doing so. If you only put a few recipes into XML, it won’t matter what format you use. If you only have a few recipes that you want, and they’re in a different format, then in theory you can transform them with XSLT or something like that. And until the number of people that will dramatically want to encode recipes in XML, but that don’t know XSLT, is large enough, there won’t be a catalyst for the “average person” to want to encode recipes into XML.
Now, in a future where technology actually works right, one can imagine doing something like walking into a kitchen and saying “record recipe” and a system automatically records what ingredients are being put into what, when they’re being stirred, sifted, cooked, etc… until one says “end recipe recording”, and then there’s an XML encoding of the recipe.
Until that day happens, XML encodings for recipes will likely be of limited value to the average person, IMHO.
But when that day does happen, do you want the encoding to be an open standard? Or a proprietary (albeit XML based) standard? If you have strong opinions now, fight for what you believe in.
I know I’m being a bit harsh on FormatData by calling the license not an open standard. But it is, honestly, not an easy to understand license. The intentions are not clear from the beginning, and the fact that the terms affect third-party software suggests that they’re trying to force people to advertise for them - for example, if I write something that uses their format, I have to include notices all over the place saying that I’m using their format. As such this is incompatible with, for example, the intent of the LGPL, which specifically is designed for people to produce libraries that can be used in commerical software without needing to cite the source of the library.
Great minds, et al. You and Scott Johnson should talk. We have a special Feedster wizard to generate Recipe Feeds that will be available shortly.