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 <<var name='support'/>> From: Web Feedback Form <<var name='feedback'/>> 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: <a href="<var name='BASE1'/>"> 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.