Yes it is planned, with some new features.

Your suggestions would be helpful and appreciated, as well as describing your use-cases for XML Content.

Weam,

My apologies in advance for not having the right XML terminology to hand etc. It would take me 8 hours of revising to re-wrap my head around what I only ever new in theory in the first place. Also it is dangerous to ask for suggestion as you will get a 5 man years project to do in you daily 5 free minutes a day ;¬)

Typical use cases are single XML file from a wholesaler that needs to be broken down into individual node items for an online shop. Or XML discography in to individual Disc nodes etc.

There are some aspects I would like to see:-

- DOM etc. for manipulation of the output data

- Same data different transforms/views

- child-nodes based on XML data subsets

- using the nodes XML data to populate the nodes taxonomy

DOM Output filters

Could DOM be done through an output filter as well so that data can be sorted and filtered as well as being transformed?

Input/Import Filters

Leaving original data intact and only manipulating the output is a fine default principal, but not always the practical approach. On large XML data files, or complex XSL, performing manipulation each time a page is rendered could be very resource heavy. So, for less processing, optional DOM / XSL during the XML input/import so that the XML data can be permantly altered.

Choice of embedded or external XML data

Your module sounds excellent and certainly would take me a long time to learn the skills to write it myself from scratch. But whilst it does have flexibility in being able to apply any single XSL transform to a nodes XML content it is restricted in that you can't view the same data on different pages transformed by different XSL i.e.:-

An output filter to run before the others that will replace a string reference to an external XML data source with the actual XML content. e.g. for a local uploaded XML data file:-

Body:
<XML_Content SRC="/files/xml-data/stock.xml">

Or for external data sources such as:-

Body:
<XML_Content SRC="http://www.supplier.com/files/xml-data/stock.xml">

With one data source you could then have different nodes reference the same data to produce different outputs such as "stock level report" and "stock turnover" etc. This I would imagine be a fairly simple addition that would extend capability substantially?

Child XML or transformed Nodes

Two different approaches to this but similar issue. The XML data may be a stock/price list, but your site will probably need to have a node per stock item e.g. so a online shop can be populated.

Dynamic child-nodes

Each child node contains no actual data, and instead generates it's body content, title and even it's existence from a decompile of a master XML node or file. i.e. node hooks are redirected to fetch their data from the single XML source rather than from the node_revision table.

Actual child-nodes

When the master XML Content node is created or altered, or at an time interval the master XML file/source is re-indexed, XML nodes are created or deleted based upon the data items contained in the master XML.

Neither approach would seem easy to impliment, but it is probably more often than not that XML derived nodes will be required to be extracted individual records from a compiled XML list of items.

AutoTaxonomy from XML tokens

If node content is effectively being created from externally created XML data then catagorising the data manually can rather defeat the purpose of using a automated data source.

With embedded XML a DOM(?) query to a pre-configured criteria could suck out a value from the XML data to populate taxonomy fields during node editing (e.g. when XML is pasted into the node). But for external file or source XML this would need to also have a CRON task run to re-taxonomy XML nodes at pre-configured durations.

Hi John,

Thank you for your comments. I did not have the time to go through them entirely, but here's first feedback after skimming through what you wrote.

Regarding the performance issue, the solution would be doing appropriate caching of the resulting HTML, and not altering the data. In fact this was scheduled some time ago; issues to consider are when to flush the cache.

As to being able to line up multiple XSL filters to run at a time, I considered that at the beginning; the thing is that it is relatively simple to do, but you know starting up such an endeavour might easily end up in attempting to do something like Apache Cocoon. I wanted to keep the module within drupal's CMS playground.

Having multiple XSL's for a single XML may be a good idea; yet we will have to study how will this integrate with the system. Are we trying to create a views-like behaviour for XML Content? This also applies to the idea of having precise control over child nodes (summarizing your child nodes section). I am actually considering CCK and Views integration in the next release of the module.

OK that is what I can say so far. I know it doesn't address all your remarks, but I will be back to them soon, and I thought I would throw my thoughts in. Comments are always appreciated.

Regards,

Weam

I see there is a Drupal 6 module now. I will experiment with it in a few days on a prototype site with large XML file attachments.

OK great, update us with the results.

P.S. I'm keeping the issue active to continue the use-case discussion.