[Zope-dev] Zope Object Tree Transformations and XSL

[Michel Pelletier]

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