Of course Zope must eventually move into the XML world. Zope needs to do templates. XSL also does templates. In fact templates are almost as central to XSL as they are to Zope. I would suggest that Zope should use XSL template syntax for DTML templates as far as is possible. In fact, maybe when XSL becomes popular enough, it might make sense to describe the interaction between Zope and the Python runtime in terms of XML transformations. That's for the future, though. In the meantime, the point is that the template syntax should be the same. Here are the details from the current XSL spec: "The value of an attribute of a literal result element is interpreted as an attribute value template: it can contain string expressions contained in curly braces ({})." "Within a template, the xsl:value-of element can be used to compute generated text, for example by extracting text from the source tree or by inserting the value of a string constant. The xsl:value-of element does this with a string expression that is specified as the value of the expr attribute. String expressions can also be used inside attribute values of literal result elements by enclosing the string expression in curly brace ({})." "The xsl:value-of element is replaced by the value of the string expression specified by the expr attribute. The expr attribute is required." "e.g. <xsl:value-of expr="attribute(first-name)"/>" "In an attribute value that is interpreted as an attribute value template, such as an attribute of a literal result element, string expressions can be used by surrounding the string expression with curly braces ({}). The attribute value template is instantiated by replacing the string expression together with surrounding curly braces by the value of the string expression. The following example creates an IMG result element from a photograph element in the source; the value of the SRC attribute of the IMG element is computed from the value of the image-dir constant and the content of the href child of the photograph element; the value of the WIDTH attribute of the IMG element is computed from the value of the the width attribute of the size child of the photograph element: <xsl:define-constant name="image-dir" value="/images"/> <xsl:template match="photograph"> <IMG SRC="{constant(image-dir)}/{href}" WIDTH="{size/attribute(width)}"/> </xsl:template> With this source <photograph> <href>headquarters.jpg</href> <size width="300"/> </photograph> the result would be <IMG SRC="/images/headquarters.jpg" WIDTH="300"/> When an attribute value template is instantiated, a double left or right curly brace outside a string expression will be replaced by a single curly brace. It is an error if a right curly brace occurs in an attribute value template outside a string expression without being followed by a second right curly brace; an XSL processor may signal the error or recover by treating the right curly brace as if it had been doubled. A right curly brace inside an AttributeValue in a string expression is not recognized as terminating the string expression." http://www.w3.org/TR/WD-xsl Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Sports utility vehicles are gated communities on wheels" - Anon
Paul Prescod wrote:
Of course Zope must eventually move into the XML world. Zope needs to do templates.
It already does, via DTML.
XSL also does templates.
I would have thought that XSL *was* a template mechanism. What do you mean by "template"?
In fact templates are almost as central to XSL as they are to Zope.
I would say far more so,
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. 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. 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. Given the very different natures of DTML and XSL, I don't see much point in making the syntaxes all that consistent.
In fact, maybe when XSL becomes popular enough, it might make sense to describe the interaction between Zope and the Python runtime in terms of XML transformations.
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. In other words, I see XSL as an alternative to DTML, not another form of it. 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. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (540) 371-6909 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.
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.
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.
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).
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. 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.
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. But that is a difference in degree, not in kind. 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? 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?
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. [*] 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. All I'm saying is that the next generation templating syntax should be XSL-based.
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? It seems better to just use XSL syntax, either extended with Python expression syntax or not. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Sports utility vehicles are gated communities on wheels" - Anon
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.
Jim Fulton wrote:
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.
Sure, but read my second sentence above. According to the Zope documentation, one of the goals of DTML is to allow a separation of responsibilities between graphic designers and programmers. Don't we expect graphic designers to be editing their stuff in XML editors in the future? If so, "DTXML" must be at least well-formed XML.
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.
Maybe not. I started out trying to answer the question that was posed to me at SPAM 7 about how DTML and XML should work together. Perhaps I misunderstood the question or Paul E. didn't know that you already had the answer.
The difference between XSL and DTML run far deeper than syntax.
Agreed. All I'm saying is that you need a syntax and it makes sense to as-far-as-possible reuse syntax. For instance, your current syntax for embedding template instructions in attributes is <el a="<!--foo-->">. That isn't valid XML. The XSL syntax is <el a="{foo}"> Not surprisingly, that IS valid XML.
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.
Actually, XSL has a simple concept called xsl:for-each. It may or may not be worth unifying at that level, however. I was mostly thinking of the syntax for: * static elements and attributes * evaluated attribute values * evaluated text creation * evaluated element type names * evaluated attribute name/value pairs Admittedly, XSL doesn't have a publicly available syntax for the last two yet.
XSL is rule-based. You don't say "interate over this and within this iteration output X and then output Y".
You can, if it makes sense. I'm not 100% sure, in fact, if you really need the multiple-rule feature, or if you could do everything top down with iterators and conditionals. But the multi-rule way is certainly more convenient.
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
That's true, but you are talking about flow of control and not the template syntax. I'm not suggesting a change in DTML flow of control. For good reasons it is function-call controlled.
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?
Actually, to me it is. I think that's why we're talking past each other. I won't go into much detail responding to the rest of your mail, because I'm really not asking for DTML to become an XSL implementation. I'm just saying that where ideas are shared, the syntax can be shared. Thus my list above. If enough syntax can be shared that DTML becomes merely a non-standard variant of XSL, then great. If we can even think of the entire document base as an XML document, that would be even cooler. I'm not willing to propose either of those yet, however. Right now I'm just pointing out that XSL has a reasonable syntax for some things that "DTXML" needs to do. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Sports utility vehicles are gated communities on wheels" - Anon
Paul Prescod wrote:
Jim Fulton wrote:
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.
Sure, but read my second sentence above.
According to the Zope documentation, one of the goals of DTML is to allow a separation of responsibilities between graphic designers and programmers.
Yup.
Don't we expect graphic designers to be editing their stuff in XML editors in the future?
Don't know.
If so, "DTXML" must be at least well-formed XML.
Yes.
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.
Maybe not. I started out trying to answer the question that was posed to me at SPAM 7 about how DTML and XML should work together. Perhaps I misunderstood the question or Paul E. didn't know that you already had the answer.
I don't have the anwer. I just don't think XSL is it. :)
The difference between XSL and DTML run far deeper than syntax.
Agreed. All I'm saying is that you need a syntax and it makes sense to as-far-as-possible reuse syntax. For instance, your current syntax for embedding template instructions in attributes is <el a="<!--foo-->">. That isn't valid XML. The XSL syntax is <el a="{foo}"> Not surprisingly, that IS valid XML.
I see. (snip)
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
That's true, but you are talking about flow of control and not the template syntax. I'm not suggesting a change in DTML flow of control. For good reasons it is function-call controlled.
Ah. Good.
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?
Actually, to me it is. I think that's why we're talking past each other. I won't go into much detail responding to the rest of your mail, because I'm really not asking for DTML to become an XSL implementation. I'm just saying that where ideas are shared, the syntax can be shared. Thus my list above.
I see.
If enough syntax can be shared that DTML becomes merely a non-standard variant of XSL, then great. If we can even think of the entire document base as an XML document, that would be even cooler. I'm not willing to propose either of those yet, however. Right now I'm just pointing out that XSL has a reasonable syntax for some things that "DTXML" needs to do.
If I understand you, all you want is to borrow some expression syntax from XSL so that an XML-formatted variant of DTML could have well-formed attribute values. This makes a lot of sense. I'll reread your original post in that light. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (540) 371-6909 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.
participants (3)
-
Jim Fulton -
Jim Fulton -
Paul Prescod