Posted by Steve Driessens on November 16, 1998 at 22:30:12:
In Reply to: Re: Transferring data between recipe management applications. posted by Matthew Starobin on November 16, 1998 at 13:04:53:
G'day Matthew,
You raise some valid points in your reply. All problems that we, too have wrestled with in the past.
This is the reason that I suggested XML as a possible path to recipe exchange 'enlightnment'.
For anybody else following this thread, XML files are just text files with various component elements consisting of their names and values. Each element can have any number of optional, component elements (fields), etc. This is, of course, a grossly simlpified description of XML, but hopefulle you get the idea.
As long as everybody uses the same, standardized, names for the elements (fields) in a recipe XML file, any application could import those fields that the application is designed to interpret and just discard those fields that the application does not recognize.
For instance, an 'ingredient' element could have an optional cost field associated with it. Applications that don't perform any kind of recipe costing calculations could just ignore each ingredient's cost field and process the remaining fields.
The recursive nature of recipes would be no problem at all in XML. Most of the XML tools that I've seen display the contents of an XML file in a 'Tree' structure, which is, of course, a great way to visualize recursive data. XML places no limits to how many component elements a 'top-level' element may have, hence the number of component ingredients in a recipe can be from zero to anything you like.
As for handling imported units, how an application handles the actual contents of a data field is up to that applicaton and not really a file format problem (as I see it anyway). I can certainly sympathize with what you say though. I've written code to look for misspellings of units like 'gram' (i.e. 'g', 'gm', 'gms', 'grammes', etc) and convert them to the correct term. But, it doesn't seem to matter how many variations I look for, someone always manages to come up with something new.
You mention importing recipes into an application from XML. I.e. do we need to read top-level recipes before bottom-level ones, etc. My gut feeling is that when generating an XML recipe file the data should be generated starting at the lowest level item proceeding up the tree to the top most item. I.e. Ingredient first, followed by lowest level recipes up to highest level recipes. This is the technique I used when designing the Recipe Exchange Format (RXF) files that we use with our applications. Someone else may have a better idea though.
I'm glad to hear that someone else is at least considering, or has considered, this matter. I contacted a number of food service software developers a couple of years ago in an attempt to get some kind of industry standard format for recipe data, but nobody wanted to talk about it. Hence, we have the situation now where there are many recipe management applications on the market, but very few of them can talk to each other, which, from the end-user's perspective, really sucks!
I could, of course go ahead and develop my own XML files, but I'd really like to get some input from others in the food service software industry to make the resulting files as flexible as possible.
Please let me know whether you're interested in pursuing this matter further or not, as I'm very keen to see an established standard. I figure the more developers that get invloved in this the better, and I'm certainly prepared to put in as much time as necessary to see a beneficial outcome for all.
One of the things that I'm also prepared to do is develop XML import/export libraries and release them onto the public domain (along with source code) to ease the burden of implementing such a scheme for other software developers.
Anyway, Matthew, that's enough raving for the moment. I look forward to hearing your thoughts.
Regards,
Steve