[Zope] XDTML

[Otto Hammersmith]

Okay, here it is... how I think DTML could be represented as XML.

The 'var' Tag

This tag provides an awful lot of functionality. I think my suggestion
would be to deprecate using 'var' as a linking element and create a (or
set of) new element(s) based on XLink. 

The 'if', 'elif', 'else' and 'unless' Tags

The problem with 'if', is the way Zope structures it currently- it can't
be translated into well formed XML. It looks something like this:
<if expr='...'>
<elif expr='...'>
<else>
</if>

There are alternatives with various advantages and drawbacks. 

The first option:
<if>
Option 1.
</if>
<elif>
Option z.
</elif>
<else>
Default option.
</else>
The advantage is it's nice and clean. The drawback is using an
event based parser makes it a little harder to parse, though not
impossible.

Another option:
<if expr='...'>
Option 1.
<elif expr='...'>
Option 2.
</elif>
<else>
Default option.
</else>
</if>
This is just plain ugly, but it should be easier to parse.

I think the best solution is what XSLT uses. The 'if' conditional is
limited to a single conditional and a second element ('choose') is
defined with syntax similar to C's switch. I don't think there are any
severe disadvantages here. They would look like this:

<if expr='...'>
Optional.
</if>

and

<choose>
<when expr='...'>
Option 1.
</when>
<when expr='...'>
Option 2.
</when>
<otherwise>
Default option.
</otherwise>
</choose>

The 'unless' tag is simply an 'if' with an implicit negation of the
expression. I don't think there is a need for a similar compliment to
the 'choose' tag.

The 'in' Tag

This one is a straight forward conversion. It would look something like
this:

<in name='employees' sort='name'> 
 ...
</in> 


The 'with' Tag

Another straight forward conversion.

Some examples from the DTML manual translated to XML.

<with name='subfolder'>
<var name='title'/> 
</with> 

<with expr="_.namespace(profit=price-cost, title=product_name+'
summary')"> 
<h3><var name='title'/></h3> 
The profit is <var name='profit'/> 
</with>

The 'call' Tag
Again a very simple conversion. Here is the example from the manual
converted to XML:

<call expr="addDocument('hi','display a greeting','Hello world!')"/>

As has been mentioned by others, it might be nice to be able to include
an entire script in a 'call' element, but that's an entirely different
issue.

The 'raise' Tag
Yet another simple one with a converted example from the book:

<raise type="Insufficient funds"> 
<p>There is not enough money in account <var name='account'> 
to cover the requested debit amount.</p> 
</raise> 

The 'comment' Tag
This tag would be obsolete, as the standard XML comment delimiters (<!--
-->) are no longer overloaded. It may be worthwhile to provide something
similar to xsl:comment, which inserts a comment into the result.

The 'tree' Tag
The 'tree' tag has the potential to be a complicated conversion. I will
make a more significant attempt when I create the first draft of the
DTD. One thing I will consider is using XLink/XPointer to replace the
header and footer (possibly more) attributes. Here is a conversion of a
the simple example given in the DTML manual:

<tree> 
<var name='id'> 
</tree> 

Ultimately, it may be best to leave the 'tree' tag as it stands and
create a new version that incorporates XLink/XPointer.

The 'sendmail' Tag
This should be simple as well. Here is a translated example:

<var name='standard_html_header'/>
<sendmail smtphost="gator.digicool.com"> 
To: Product Support &lt;<var name='support'/>&gt;
From: Web Feedback Form &lt;<var name='feedback'/>&gt; 
Subject: <var name='subject'/> 

<var name='body'/> 
</sendmail> 

Thank you for your input! 
<var name='standard_html_footer'/>

Other Issues

One problem that was brought up was having an output element with an
attribute of a dynamic value. For example (in DTML):

 <a href="<!--#var BASE1>">

(Note, this may not be the best example since the functionality of this
code is easily replaced by some kind of XLink support. However, it is
easy to envision another case- setting the class attribute, for
example.)

The easy solution is this:
&lt;a href=&quot;<var name='BASE1'/>&quot;&gt;

This is obviously ugly and hard to write. XSL solves this problem with
two new elements, xsl:element and xsl:attribute. If I read the XSLT
draft correctly it would look something like this:

<a>
<xsl:attribute name='href'>
<var name='BASE1'/>
</xsl:attribute>
Contents of the element.
</a>

What Good Is XML?

XML gives us a standard, relatively easy way to programmatically modify
a document.  This ability makes it trivial to write a document that
changes without the intervention of the author.

Take, for example, a page hit counter. With current methods counter data
must be stored somewhere outside the document. If I move the document I
have to manually modify the external data or I loose the current count.
What I'd like to do is contain that count in the server side document. 

A good term might be "server side dynamic documents". This is different
than the usual dynamic documents with JavaScript in that processing
takes place on the server and changes are universal across clients.

This is how I envision the counter example might work. 

<?xml version='1.0'?>

<xdtml:xdtml xmlns:xdtml='...' xmlns:xhtml='...' xmlns:count='...'>
<count:hits count='28'/>

<xhtml:h1>NiftyTitle</xhtml:h1>
<xdtml:call expr='increment("hits")'/>
<xhtml:p>This page has been hit <xdtml:var name='hits'> times.</p>
</xdtml:xdtml>

A couple things that would probably change:
1) The var tag would really be an XLink element pointing to the contents
of the hits element for inclusion.
2) The function 'increment' would probably be very different. Ideally,
there would be a library of functions designed to mangle XML documents
in common ways and, of course, the ability to fall back on a full-blown
DOM interface.

The traditional counter that covers a whole site could be done with a
single document that only holds the counters. Each document that wanted
to include that count would simply have an XPointer to another document.
Every document that wanted to update the counter would have a line that
updated the hits element on that other document.

(Note, this can be done currently, I believe.. but the parsing of the
DTML is not quite as straightforward.)

				-Otto.