We came across a (slightly) similar problem which may assist you.
Our problem was with BIRT, the Eclipse report generation tool. It's a fine product but required the use of the BIRT Eclipse Designer (GUI) to generate the report definitions (tedious at best, buggy in early version, specifically with copying and modifying report designs, which was the only way to quickly make a lot of similar report designs).
Since we wanted a batch approach to be able to generate hundreds on report designs at a time (and to be able to change small stylistic things and re-generate the whole lot again), we opted to create our own Java-based tool which would take our simple report specification (50-odd lines) and turn it directly into a BIRT XML report design file (thousands of lines).
We already had the simple report specification files since our reporting subsystem already existed - we were just adding web reporting as an option to it.
It worked because all of our reports follow the same basic format - we didn't need very complicated stuff in them.
What it entailed was to use the GUI to create a couple of reports then reverse engineer them to figure out how to generate the BIRT XML from our specification files. This was the hardest bit.
It seems like you could follow a similar approach with your slideshows. Use the GUI tool to generate the sort of XML files you need then reverse engineer them.
So, I would create a totally empty slideshow with no content, then create one slide with text, another with animation, another with an embedded OGG and so on, then compare the steps to see how the XML changes for each added element.
Then you can create a tool which takes your simple commands (e.g., add-slide
, add-ogg
, add-text
, add-bullet
) and spews forth the relevant XML. We didn't use XML as the source (since I can't stand the verbosity) but, if you do use it, it may just be a matter of XML transformations to get what you need.