Hi, Stephan:
As I skimmed the post (sorry), can you just clarify: are you talking about a variant on the XML-->XSLT-->desired output approach, or are you discussing something new? When I read this:
Quote:
|
I'm now going to build such workflows for more common input, that is XHTML or EPUB to process any kind of text automatically into various output formats. As a first step, I started to develop a small tool html2epub (which is in a very early stage, CSS in the header gets lost etc.). I plan to work on a full processing backend to support output in XHTML, EPUB2, EPUB3, PDF via FO, PDF via LaTeX, plain text.
|
Am I to understand from this that your intent is to take existing ePUBs and XHTML, and...what? Work it back to XML, so as to then support the output to these other various formats?
FWIW, a company in Chennai has already developed, and will be showing demos on, a process that takes existing XML input, parses it, and then puts the existing "book" into a browser-like interface that "looks" like Word for authors and editors, so that they can edit on the fly, collaboratively, save the output, and then it's parsed back to XML, and provided (this is the part that cracks me up) "to the bookmakers" so that the bookmakers can make the book all over again from XML.
So...in short, do you mind restating what it is you're doing? I admit, from my point, XHTML/ePUB is the output, not the input, so I'm pondering, other than converting ePUB to Markup, what the goal is here?
Thanks!
Hitch