[Zope] - Re: [XML-SIG] Re: [Zope] - Zope, DTML and XML

[Jeffrey Shell]

> Right, but DTML code is not valid XML code. It can't be 
> edited in an XML
> editor, stored in an XML repository, routed through XML-based 
> workflow,
> etc. etc.

But using DTML you can generate any kind of XML that you want, and get
the level of effectiveness that you are stating.  And then that
generated XML can be routed through all the XML based workflow that you
want.

I've done a couple of relatively small experiments with this, once using
DTML over a sequence of Tabula records to generate a good size XML file
to test an XML parser.  So it was an XML expression of objects in the
database, but using DTML allowed me to make the XML structure that I
wanted independant of the structure of the Zope database or the Tabula
database or what-have-you.

And even that doesn't stop you from using XSL directly in Zope.  On NT
*twitch* with IE5 *twitch* you could make a Zope object to call
Microsofts XSL processor.  Then you could have a DTML page that goes
over some sort of query to return an XML document linked to the XSL
style sheet.  Add another document that calls the XSL processor and
passes in the rendered XML document, and Walla!

> > > I would suggest that Zope should use
> > > XSL template syntax for DTML templates as far as is possible.
> > 
> > It appears to me that DTML and XSL represent two very different
> > approaches to solving the same or similar problems.  They are
> > both intended for generating text from objects.  DTML generates text
> > from Python objects.  XSL generates text from XML objects.
> 
> Not quite. XSL generates XML objects (technically speaking, 
> "nodes") from
> other XML objects (other nodes).

Using XML to go through XML and generate XML?  :)

> The big difference, of course, is that XSL's set of 
> expressions is quite
> limited where as Python is quite flexible. That's why I 
> propose using the
> same syntax but changing the expressions to be Python expressions.

Doesn't this kill off any sort of 'XSL portability'?  I can imagine a
system where both Zope and, say, Access *twitch* (independantly of Zope)
could generate XML documents of the same or similar DTD and have the
same XSL document(s) be able to render them both on an entirely
different machine.

> > Given the very different natures of DTML and XSL, I don't see much
> > point in making the syntaxes all that consistent.
> 
> Do you have another XML-compliant syntax in mind or have you 
> decided that
> XML compliance isn't critical?

It's easy to write some DTML to generate XML.  There's a big piece of
compliance right there.  Currently, there's no XML on the intake side.
I think this is a _far_ more important thing to do than spend a bunch of
time writing yet another XSL parser.  I would rather be able to generate
that phone book file as XML and be able to upload it into Zope as
intelligent-ish Zope objects (into a Tabula, as Zope Folders, or
who-knows-what) and write a simple

<!--#in "phone_numbers(zip=22401)"-->
 <TR>
  <TD><!--#var fullname--></TD><TD><!--#var phone--></TD>
 </TR>
<!--#/in-->

DTML document rather than the complex XSL involved.  Then I can add the
ability for people to add new phone numbers and modify their entries in
this dataset and re-export it to a new updated XML file, and use some
other XSL parser to generate a printable phone book, PDF, RTF, and HTML
from that.  The XML file can be easily done in DTML by:

<?xml version="1.0">
<phonebook zip="<!--#var inZip-->">
 <!--#in "phone_numbers(zip=inZip)"-->
  <listing for="<!--#var fullname-->">
   <fullname><!--#var fullname--></fullname>
   <phone><!--#var phone-->
  </listing>
 <!--#/in-->
</phonebook>

> > It may very well. If Zope made it easy to generate XML from 
> Zope (ie Python)
> > objects, then people who  like XSL could apply XSL 
> transformations to the
> > resulting XSL, bypassing DTML altogether.
> 
> Sure, but how do I specify the objects that I want to work on 
> from the XSL
> stylesheet? You can't [*] export the database as a single XML 
> document, so
> you must allow a syntax that allows drilling into Python 
> objects: Python
> syntax.

See above.  There's a few variations that can be done.

> I don't really see the difference. Either an extended XSL 
> replaces DTML or
> an XSL-syntax DTML replaces DTML. All I'm saying is that the next
> generation templating syntax should be XSL-based.

XSL is _much much much_ tougher for beginners to Grok.  It's very very
powerful, yes, but sometimes just to do a simple tabular based report in
it is waaaay too much of a headache.  We discussed this a long time ago
here at digicool with just an XML based replacement for DTML (XSL was
just barely off the drawing board at the time of these discussions).  I
still emphasize that it's (a) not that hard to generate complient XML
using DTML (the DTML document itself doesn't have to be XML complient,
just the document as rendered), and (b) importing XML should be a bigger
priority.

just my <CURRENCY STYLE="cents">.02</CURRENCY>.