You are not logged in Log in Join
You are here: Home » Members » jim » ZDOM-save » ImportTemplates » wikipage_view

Log in




(Uche 2000-04-27)

We have discusse the requirement for parameterization when importing XML documents into Zope. Several solutions have floated about, from using plain old DTML to inventing our own "Zope Import Template Language", but while working with XMLDocument? today it occurred to me that the most elegant solution is already a standard: XSLT.

This might be hard to follow if you are unfamiliar with XSLT, but I'll try to make it strightforward:

Say we have an input document:

<x:store name="Widget Shop I" xmlns:x="">
  <x:item sku="12345">
    <x:desc>A fine widget</x:desc>
  <x:item sku="38670">
    <x:desc>A blue gee-gaw</x:desc>

Let's say we want to stipulate that store tags come in as folders and items as ZDOM element objects with desc and price as attributes on those element objects.

<xsl:stylesheet version="1.0" xmlns:xsl="" xmlns:z=""

<xsl:template match="/x:store"> <z:folder id="translate(@name, ' ', _)" title="@name"> <xsl:apply-templates/> </z:folder> </xsl:template>

<xsl:template match="x:item"> <xsl:element name="{@sku}" namespace=""> <xsl:attribute name="desc" namespace=""> <xsl:value-of select="x:desc"/> </xsl:attribute> <xsl:attribute name="price" namespace=""> <xsl:value-of select="x:price"/> </xsl:attribute> </xsl:element> </xsl:template>


This basically uses XSLT extension elements to genrate special Zope objects such as Folder, with regular XSLT instructions for generating the corresponding ZDOM objects.

This has too many advantages to list here, but a few are:

  • Would be fairly straightforward to implement, building on 4Suite
  • Is a standard (XSLT supports extension elements, and XPath? extension functions)
  • Harnesses the tremendous power of XSLT and XPath?. Matters such as white-space can be handled by XPath? finctions such as normalize-space()
  • Zope users could define their own extension elements, for instance, if they had a custom ZClass? names "item", they could use a "" instruction to generate it.
  • no additional learning curve for XSLT users
  • this would be one of the coolest uses of XSLT within an application that I've heard of. It would definitely get the XML community interested in Zope.

The main disadvantages are, of course, that it is verbose, and that it would be quite a learning curve for non-XSLT types.

(2000-04-26 Mike)

Uche, excellent Idea with XSLT. Two points, first this will only cover one aspect of the Import Templates, the mapping from Element/Attribute to Object/Property. You did touch on extending XSLT we could also extend to add these other features. Secondly, you won't need to extend XSLT for things such as folders. An elements tagName is its python class so the document will be smart enough to know how to biuld a Folder (or DTMLMethod?, or FooWidget?).


(Uche 2000-04-27)

I forgot to mention another advantage is that we can do away with the automatic element titling that XMLDocument? does. This is one of the most unfortunate features of the current XMLDocument?: XML is all about structures semantics, and XMLDocument? kills this with its "e11" etc. XSLT gives the developer full control over object naming and attributes.

Also, as Mike pointed out, nothing special is needed to build a Zope folder. Extension elements really only make sense for custom Zope types (although I guess one could embed DTML in an XML tag and then use an extension element to generate a DTMLMethod? object. Then voila! Embedded scripting.

One more note: Output templates would be just as easy with XSLT using ZDOM. That way, the developer could round-trip the semantics lost when, say, price was converted from sub-element to attribute.

I should note that today I did some research and thinking of how we might want to integrate XLinks?. I know this is not a deliverable for this project, but I wanted to be sure our current thinking didn't preclude such an important next step.