Josh Zeidner wrote:

Hello everyone,

Currently we are facing a problem with a Zope-based application where we need to be able to *view* a tree of ZObjects as another tree of ZObjects with an entirely different structure. If these objects were XML elements I could use XSL- however, they are not.

They can be as much XML as any other XML. XML is not a thing, it's a view of a thing. The Zope objectspace is one big DOM so I'm pretty sure that what you want is possible to do. There are some problems, however. XML in Zope is not complete. Not complete in that many of the things that go on in XML are not *yet* in Zope. This is not because Zope is not engineered well to be a 'XML platform', quite the contrary, it's just that we have not yet integrated the tools to do the kind of things like this that you want to do. This is for a number of reasons, all of which are my personal opinion and not the official company line: o XML's uses have not been completely mapped, and certain uses for XML are useful and others are not. This evolutionary contest is still being fought on many grounds, we like to avoid such bloody battles because we don't have much room to 'waste our time' implementing some XML thingy that eventally turns out to become exstinct. Note that I don't mean things like XSL here, but rather things like how objects are represented in XML, how that information should be interpreted by other systems, etc. etc. Currently, Zope objects import and export themselves to a 'proprietary' flavor of XML. o We have not considered how to engineer existing Python tools into Zope and how to do it well. So far we have integrated a DOM model on top of all Zope objects, and we have created an 'XML Document' that is a useful object as well as a useful learning experience for using pyexpat within Zope, we have implemented XML-RPC, and objects can 'export' and 'import' themselves to an XML view. There are many uncharted territories however. Many of those territories many be fruitful to chart, others many not be. For example, I am of the personal opinion that storing XML as the final format for objects is silly. It introduces incredible overhead for data that no 'human' ever needs to read and that can be transformed to and from XML trivially on demand and transparently to any system that needs to be fed XML. However, others have expressed that Zope will become useless unless it follows some sort of pure XML path in which every possible piece of data is encapsulated in XML. I think these people take XML too seriously, it's perfectly reasonable to use your existing system and framework and fast proven database AND provide a reasonable framework for viewing this information in XML. Actually storing it in XML introduces overhead for all systems that is just not neccesary. If fast compressed binary pickles can be transformed trivially and isomorphically to XML and back, then why store the slow format that you have to parse and generate on every read and write? Anyways, I'm totally digressing from your question here. But it is a bit relevant in that it sounds like you are trying to transform a collection of python objects from one view to another. As you've said, you could transform one XML into another XML using XSLT, but why not just use python to trasform this view of python objects? It's perfectly reasonable and as complex an exercise as it would be in XSLT. Your alternative is to convert all of the objects to an XML representation (possible now) transform it with XSLT (you would have to integrete some existing tool or use an outsite tool) and then convert the transformed XML back into objects (possible now). This seems like a lot of overhead to me for something that can be done just as easily (I would argue easier, but I'll maintain equivalent ease for the sake of argument) with a python algorithm. -Michel