By itsme213 on

What about a content conversion architecture that looks like this:

--> INPUT converter --> Internal Rep      --> OUTPUT converter

    Wiki-in                                   
    OOo-in        -->   XML(for example)  --> XML out (incl. XHTML)
    XML-in                                    PDF out
    MsOffice-in

The converters could have an internal architecture that allowed them to be combined, piped, etc. If categorizing is part of the Internal Rep, then input streams could be piped, after basic format conversion, into a Categorizer component that could either categorize automatically, or require user input. Themes/templates could be part of the (XHTML) OUTPUT converter.

Thoughts? Disclaimer: I am a Drupal newbie

Comments

javanaut’s picture

javanaut commented

I think maintaining an internal abstraction of a node would be a great idea. It would offer a maximum of flexibility for output formats and offer a consistent data collection for internal management. Unfortunately, at this point, it would require a complete rewrite of most modules, as well as the whole node subsystem. For these reasons, I think you may find resistance while trying to motivate people.

Brian@brianpuccio.net’s picture

Brian@brianpuccio.net commented

This sounds like a great idea. Let's say I was a math teacher and wanted to use Drupal as courseware. Math nodes, for example, could be offered in XHTML 1.1 + MathML, or XHTML + CSS, or as a LaTeX document, and from that, even a PDF could be gereated. All from the same source.

Or, let's say I was a musician. Each music node could be stored in MusicML and converted to MIDI or MP3 for people to download.

Disclaimer: this is way over my head and I wouldn't know the first thing about how to do this, let alone how to do it right.

puregin’s picture

puregin commented

Node contents already have a universal internal representation, namely, strings. There's nothing to be gained in generality and much to be lost in many other regards by adopting an XML representation.

Of course you are free to store XML in nodes if you have an application that requires it. However, if you want support in terms of XML editors, XML diff, validation, search and transformation tools, there's currently nothing for Drupal. Might such features be useful for some applications? Without question. Are they a priority for most applications? Probably not. You're likely better off building on a platform targeted to XML.

The existing architecture already supports content filters, and even transformation (as in the case of PHP code). Modules are free to transform node contents as required.

Importing from and exporting to files seems to be addressed by the import-export module, as well as node-import and perhaps some other modules. There are many stream filters 'out there' which can be applied to effect specific conversions (man2html, latex2html, html2pdf, doc2html....)

There are certainly issues to be explored with respect to compound and structured documents (e.g. books) Unfortunately, I don't think that there is a one-size-fits-all solution.

--
puregin