I’ve been creating assorted SWFObject examples for a few months now, usually in response to a forum post at the SWFObject forum. These examples have been piecemeal, just kinda floating out there with no clear links to them or documentation explaining what they are. I decided to create a guide for the examples, which gives a little bit of background for each example as well as the URL for each example.
But I found another Microsoft product helpful today.
It pains me to say it, but it’s true.
I have created an XML template for an online course delivery system I’m building at my workplace. The course data for each course needs to be placed into a copy of this XML template. The problem is that I don’t want to work directly in XML all day, and my coworkers can’t be expected to write course content directly in XML format. I needed to devise an easy-to-use method for inputting data to an XML document (filling in the blanks).
My initial research into the subject found some ‘export-to-XML’ methods that use Excel and/or Word, but they are prone to formatting errors and require extensive workarounds such as oodles of conditional formatting. Didn’t sound very fun. Not to mention the custom XML schema I’d have to write to enable the Excel/Word file to be properly transformed to my custom XML. Other methods involved databases and content management systems, which I wanted to avoid for simplicity’s sake.
Enter: InfoPath. A “how’d I get that?” program that came with our Office 2003 update a few months ago. I had never heard of it until I saw it while randomly browsing my computer’s Program Files shortcuts.
Turns out it’s a program for designing forms that are connected to a data source such as an Access database or… you guessed it… an XML document. And what I truly found surprising is that you don’t need an XML schema, just a sample XML document that follows the format you want your future XML docs to be in. A copycat, so-to-speak. InfoPath will automatically infer the schema from your sample XML! Note: you should probably go in and check the schema details, such as using a “date” data type rather than “integer”.
InfoPath was very easy to use. I created a new blank form, then selected my sample XML file as the data source; InfoPath made the XML tags available as drag-and-drop items, kind of like Flash components. I quickly arranged the items how I wanted them (including using “repeating regions”), and voila!, I had a fully functional form in one afternoon. The data entered into the form is exported to a fresh XML file — based on and validated against my custom XML — whenever I hit “save.”
Of course, that’s a very simplified explanation of how InfoPath works and what it does… I’m still a newbie with the program. However, I can say it greatly simplified the work I needed to do (no crazy workarounds using multiple programs), gave me a form I can share with my coworkers (although you need InfoPath to use the form), and produced valid XML that I can import into other programs as needed, all in one afternoon.
I should note there are other programs that perform similar functions, including Adobe Designer (companion to Acrobat Professional). I will have to investigate the alternatives — I hate being beholden to Microsoft — but so far InfoPath is leading the pack.
http://office.microsoft.com/en-us/FX010857921033.aspx [link no longer available]
OK, most of you probably don’t know the difference between an XML file and an XSD (“XML Schema”) file. For a brief intro check out W3Schools’ XML Schema tutorial. A brief quote: “The purpose of an XML Schema is to define the legal building blocks of an XML document, just like a DTD.”
This week I needed to create an XML Schema doc for work. The XSD file would be used to validate XML files I’ll be making for my online courses. Well, being a newbie to XSD files (though not XML), I was making decent but very slow progress when a thought occurred to me: it should be possible to reverse-engineer an XML file to create an XSD file. And, considering how prevalent XML is these days, someone probably posted an online converter for it! Google to the rescue!
I found a number of tools (mostly software downloads such as XMLSpy), but the easiest one I’ve tried so far is by — gulp — the Evil Empire itself: Microsoft.
http://apps.gotdotnet.com/xmltools/xsdinference/ [link no longer available]
All I can say is whether you love ’em or hate ’em, their tool works great and is completely free. On my first try it pointed out some invalid XML I had written. After correcting my mistake, BAM!, I had a complete XSD file. It wasn’t perfect and needed some tweaking (optional versus required tags, string v. integer, etc.), but it eliminated most of the heavy lifting for me and I’ll be finished a heck of a lot sooner than I would have been without it.
Umm… thanks, Microsoft! (For once…)