Paul Prescod wrote:
Jim Fulton wrote:
Paul Prescod wrote:
Of course Zope must eventually move into the XML world. Zope needs to do templates.
It already does, via DTML.
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.
Is that important? Python isn't valid XML code either, but it's still useful. I think it would be useful if there was an XML-compatible syntax for DTML, but I don't see that having much to do with XSL. The difference between XSL and DTML run far deeper than syntax. (I had a similar discussion with some folks a while back wrt ASP and DTML. On the surface, DTML and ASP are similar, but the semantics are really very different.)
XSL also does templates.
I would have thought that XSL *was* a template mechanism. What do you mean by "template"?
XSL can be thought of as a template mechanism. But an XSL stylesheet has many templates and describes a flow of control between them, whereas DTML documents are a single template.
OK, OK, what ever. You know alot more about XSL that I do. :)
In fact templates are almost as central to XSL as they are to Zope.
I would say far more so,
Fair enough. I meant to say that that they are almost as central to XSL as they are to DTML. six of one...
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).
Ditto.
DTML takes a higly procedural approach. In DTML, you generate text directly. In XSL (as I understand it) you specify a set of rules for applying transformations to XML elements. This is fairly declarative in nature. In the example you gave, you didn't render a specific picture element. Instead, you have a rule for converting picture elements to img tags.
Right. But the same holds for DTML. You don't write DTML to generate an IMG tag for a specific picture.
Often you do. Or at least, you typically start out with a relatively specific thing. For example, an in tag is applied to a specific collection or to the results of a specific call (e.g. a database query). Then, code is applied to elements within the collection.
If you knew exactly what picture you wanted, you would use the HTML for it. You use DTML extensions when you want to figure out the picture to use at runtime, just like in XSL. I don't see this as a difference.
XSL is rule-based. You don't say "interate over this and within this iteration output X and then output Y". In XSL (speaking as someone pretty ignorant of XSL ;) you say things like "if you see a Foo, convert it to a bar ....". It's like the difference between Python and Prolog (or, uh, sendmail.cf ... sorry, low blow revealing XSL skepticism ;).
Another difference between DTML and XSL is in how content is determined. DTML is typically used to define as well as format content. A DTML document directly specifies data that is often extracted from large object spaces. In XSL, it appears that the content is largely defined by a source document and an XSL "template" simply specifies transformations. Of course, an XSL specification can also filter, so there is some ability to extract, but it is much less direct than with DTML.
What you seem to be saying is that DTML works on large Python object-bases and XSL works on small XML document inputs.
DTML makes calls into a large object base, typically pulling out a small subset. XSL on the other hand seems to be geared toward transforming a body of data.
But that is a difference in degree, not in kind.
It doesn't feel like the same sort of thing to me. Perhaps I'm just too ignorant of XSL.
I could encode a phonebook as a single XML document and use XSL to generate a list of all of the numbers in a particular zipcode. How is that different from using DTML in the same context to solve the same problem?
It's not different. I think DTML and XML problem spaces definately overlap. In fact, I'd be happy to drop the argument that the problem spaces are different. I still think the approaches are too different to make it worthwhile to try to turn one into the other.
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.
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?
I have a syntax in mind. But that seems to me to be beside the point. This discussion isn't really about syntax issues, is it?
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.
If this is true, then you seem to be supporting my argument that one way that the two is different is that DTML is geared toward drilling into an object space while XSL is geared to transforming a body of data.
[*] It is vaguely possible that un-extended XSL could work directly on a Zope database if we could express all Python objects as XML data... this requires more thought...but even so, you couldn't evaluate arbitrary Python code, you could only refer to preexisting objects.
In other words, I see XSL as an alternative to DTML, not another form of it.
I don't really see the difference. Either an extended XSL replaces DTML or an XSL-syntax DTML replaces DTML.
Why must one replace the other? You don't believe that there should be only one programming language, do you? I think that the approaches of these two systems apeal to different users.
All I'm saying is that the next generation templating syntax should be XSL-based.
This is what you think. We'll have to agree to disagree.
Or, DTML may turn out to be a good tool for generating XML from objects, and then XSL could be applied to DTML output, in which case the two would act in tandem.
Why have two steps?
OK, let's eliminate the XSL step. ;) Seriously, DTML and XSL have different strengths. Sometimes we combine DTML and Python, or even C, because DTML isn't good for everything. In fact, an idea that we are very fond of with Zope if that objects can have methods written in a multitude of languages (possibly by a multitude of people). Right now, it's not unusual to have objects with methods written in 4 different languages (Python, C, DTML, SQL). I'm perfectly happy to see XSL thrown into the mix.
It seems better to just use XSL syntax, either extended with Python expression syntax or not.
I don't agree. Of course, I'm happy to see people experiment. It doesn't sound to me like you want an XSL syntax for DTML. It sounds more to me like you want some sort of XSL processor in Zope (or just Python) that is extended to make calls into an object system. If you think you can adapt DTML to this somehow, go for it. I'll be interested to see what you come up with. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.