People, I'd like to share a thought I had this morning as I read a post by Stephan Richter on the zdp list. Stephan: At 11:29 am -0500 22/8/99, Stephan Richter wrote:
yep, go to my site. I have four XML documents wrapped by DTML. :) http://www.zope.org:18200/Members/srichter Works great by the way, thanks to Martijn Faassen.
It occurred to me that the Zope community now has the ability to render XML documents *on the fly* into HTML (or whatever), doing it almost transparently, and within a framework that is extremely powerful. I've been watching the XML-L and XML-DEV lists for, oh 18 months now. There have been announcements of rendering XML into HTML etc on the fly, yes. But the solutions offered have always been too clunky for me (talk of XSL and Java servlets and *much* more arcane stuff flew around and through the list and my head for many moons). In short, this is a *big* win for the Zope community. tone out. ------ Dr Tony McDonald, FMCC, Networked Learning Environments Project http://nle.ncl.ac.uk/ The Medical School, Newcastle University Tel: +44 191 222 5888 Fingerprint: 3450 876D FA41 B926 D3DD F8C3 F2D0 C3B9 8B38 18A2
Tony McDonald wrote:
People, I'd like to share a thought I had this morning as I read a post by Stephan Richter on the zdp list.
Stephan: At 11:29 am -0500 22/8/99, Stephan Richter wrote:
yep, go to my site. I have four XML documents wrapped by DTML. :) http://www.zope.org:18200/Members/srichter Works great by the way, thanks to Martijn Faassen.
It occurred to me that the Zope community now has the ability to render XML documents *on the fly* into HTML (or whatever), doing it almost transparently, and within a framework that is extremely powerful.
It's been amazing to watch how quickly Stephan figured out how it works; so far I only worked with a single type of XML document, but he's wrapped 4 already! This indicates not only that Stephan's smart, but also that it's indeed not that hard to do. :)
I've been watching the XML-L and XML-DEV lists for, oh 18 months now. There have been announcements of rendering XML into HTML etc on the fly, yes. But the solutions offered have always been too clunky for me (talk of XSL and Java servlets and *much* more arcane stuff flew around and through the list and my head for many moons).
I know next to nothing about XSL and Java servlets. I'd like to study XSL sometime, is it really that arcane? I read something about DC going to fit XSL into Zope, so I'm curious about it.
In short, this is a *big* win for the Zope community.
Definitely! Regards, Martijn
I can't claim to know a lot about XSL, but the tutorials I glanced at gave me the definite impression that it is very similar (in functionality) to DTML! The major differences seem to be that an XSL document is also a valid XML document, and that XSL has a heavy declarative/pattern-matching flavor, while DTML is purely procedural code embedded in HTML. Of course, there's the (currently theoretical) difference that XSL rendering of XML can happen on the client end. Without getting into syntax, XSL rendering seems to work like this: Start at the root of the XML document. Search for the XSL node with the pattern which most closely matches the current XML node. Use that XSL node as a template, plugging in required data from the XML subtree, and recursively process XML subnodes whenever the template requests it. Contrast this with DTML, which acts rather like a single XSL node, except that it has many flow control tags and can call on other methods. More procedural, in other words. I suspect, given Zope's new XML expertise, that you could write an XSL renderer in DTML (with a few well-chosen external methods) :-D ----- Original Message ----- From: Martijn Faassen <m.faassen@vet.uu.nl>
I know next to nothing about XSL and Java servlets. I'd like to study XSL sometime, is it really that arcane? I read something about DC going to fit XSL into Zope, so I'm curious about it.
Evan Simpson wrote:
I can't claim to know a lot about XSL, but the tutorials I glanced at gave me the definite impression that it is very similar (in functionality) to DTML! The major differences seem to be that an XSL document is also a valid XML document, and that XSL has a heavy declarative/pattern-matching flavor, while DTML is purely procedural code embedded in HTML.
All true.
Of course, there's the (currently theoretical) difference that XSL rendering of XML can happen on the client end.
Not entirely theoretical. IE 5.0 has client-side XSL rendering. It's a little out of date because the specification was not final but it isn't too bad for experimentation.
Contrast this with DTML, which acts rather like a single XSL node,
I think you mean "single XSLT template rule." XSLT has recently been reorganized so that it allows you to use it with a single rule, without declaring the xsl:stylesheet and xsl:template instructions. In other words it can now look a LOT like DTML. I look forward to when I can do DTML-type stuff in a standards conformant way.
except that it has many flow control tags and can call on other methods.
XSL has some flow control tags also: if/then/else, for-each etc. Not as many as Zope. XSL also has a notion of "foreign functions" that you can use to call into your underlying environments implementation.
More procedural, in other words. I suspect, given Zope's new XML expertise, that you could write an XSL renderer in DTML (with a few well-chosen external methods) :-D
Is that writing an XSL renderer "in DTML" or in Python? Paul Prescod
I don't think it is fair to compare the complexity of the code used here: http://www.zope.org:18200/Members/srichter with the average XSLT transformation. XSLT is specifically designed to handle recursive, heterogenous document types. These document types are the norm in real-world Web publishing. I think that XSL is what DTML would become if it was evolved toward the problem of rendering real-world XML. The fundamental question is how do you extend a template structure so that it is recursive and polymorphic. Consider this model: DOCUMENT -> TITLE, SECTION+ SECTION -> TITLE, (P|LIST)+, SECTION+ So in the rule for section you need to process the title. And then the paragraphs and lists (in the order that they arrive) and then start the process over again for SECTION. TITLE must be handled differently in the DOCUMENT and SECTION contexts, and differently depending on how many levels of SECTION down it was. This sort of thing is where XSLT excels. It would be useful if someone could outline a Zope/DTML solution to this problem. Paul Prescod
Paul Prescod wrote:
I think that XSL is what DTML would become if it was evolved toward the problem of rendering real-world XML. The fundamental question is how do you extend a template structure so that it is recursive and polymorphic. Consider this model:
DTML is recursive, however it is not polymorphic, as such would require some sort of code manipulation protcol and enhancements to the DTML security. Full polymorphism would be, of course, a plus with an added level of complexity, makes me thing of LISP and FORTH. There is good news however, a recent intern of ours developed alot of the DOM methods for Zope objects, and I beleive there was some work done in regard to XSL. Jim would have more details. -Michel
Paul Prescod
_______________________________________________ Zope maillist - Zope@zope.org http://www.zope.org/mailman/listinfo/zope
(To receive general Zope announcements, see: http://www.zope.org/mailman/listinfo/zope-announce
For developer-specific issues, zope-dev@zope.org - http://www.zope.org/mailman/listinfo/zope-dev )
Paul Prescod wrote:
I don't think it is fair to compare the complexity of the code used here:
http://www.zope.org:18200/Members/srichter
with the average XSLT transformation. XSLT is specifically designed to handle recursive, heterogenous document types. These document types are the norm in real-world Web publishing.
I don't think *recursive* documents are the norm? It may be that XSLT transformations can be far more complex, but since Stephan is doing 'real-world web publishing' with XML now, I don't think it's fair to say recursive documents are that incredibly common.
I think that XSL is what DTML would become if it was evolved toward the problem of rendering real-world XML. The fundamental question is how do you extend a template structure so that it is recursive and polymorphic. Consider this model:
DOCUMENT -> TITLE, SECTION+ SECTION -> TITLE, (P|LIST)+, SECTION+
So in the rule for section you need to process the title. And then the paragraphs and lists (in the order that they arrive) and then start the process over again for SECTION. TITLE must be handled differently in the DOCUMENT and SECTION contexts, and differently depending on how many levels of SECTION down it was.
I haven't experimented with recursive structures yet (Stephan has), but the other things you mentioned I've done with DTML. So I've used your rules, with the SECTION rule changed to this: SECTION -> TITLE, (P|LIST)+
This sort of thing is where XSLT excels. It would be useful if someone could outline a Zope/DTML solution to this problem.
A Zope XMLDocument represents an XML document as a DOM tree in Zope. Each node in the tree automatically acquires the DTML methods that are defined in the folder where the XMLDocument is (or a higher folder). We have an DTML method called 'renderDocument' which renders the node title (for instance with a H1 tag), and then for all the section nodes, calls (with dtml-var) 'renderSection'. In renderSection, the title may be rendered with H2, for instance. Then it can go through all the contents, and see if it's encountering a P or a LIST node (for instance in a renderContents DTML method). This in turn calls the renderP and renderList DTML methods. If you want to see an example of this I can send you a .zexp file (or anyone else who asks :). Having said all this, I'm sure XSLT may be suited better to this kind of task, as it's specifically designed to do such. But DTML isn't bad at all, and, if you know Zope, it's not hard to whip something up (or change how the rendering works). Once you get to recursion (changing the rendering depending on how many levels deep the recursion goes) things may become more difficult to do. Regards, Martijn
Martijn Faassen wrote:
I don't think *recursive* documents are the norm? It may be that XSLT transformations can be far more complex, but since Stephan is doing 'real-world web publishing' with XML now, I don't think it's fair to say recursive documents are that incredibly common.
Well it may not be fair but it is true. :) Even HTML and DTML are recursive (lists within lists, tables within tables).
We have an DTML method called 'renderDocument' which renders the node title (for instance with a H1 tag), and then for all the section nodes, calls (with dtml-var) 'renderSection'. In renderSection, the title may be rendered with H2, for instance. Then it can go through all the contents, and see if it's encountering a P or a LIST node (for instance in a renderContents DTML method). This in turn calls the renderP and renderList DTML methods.
Right, this is how I would do it in ordinary Python. It's quite reasonable for small projects but you have a very strict binding between your document type's schema and your code. If you add a thing called "unorderedlist" which can appear anywhere a paragraph can appear you may need to change a dozen contexts (abstract, section, list item, etc.). So eventually you get tired of hard-coding what to do with each child node. You start to think: "Python's pretty flexible. There must be a way to emulate polymorphism." So you set up an array like this: def renderSection( sectionNode ): .... handlers["SECTION"] = renderSection And then in your loop you do something like: for subel in subelements: handlers[subelement.tagName](subel) That works great for a while but then you realize that the handling of (e.g.) a title is radically different depending on its context. So it doesn't make sense to always call handlers["TITLE"]. So you allow handlers to be tuples including context and maybe attributes: handlers[("SECTION","TITLE",{"attr":"bar"})] There. You've essentially reinvented XSL. It's no more complicated than that. That's why I say that this is where DTML will end up if it seriously persues the question of how to render XML.
If you want to see an example of this I can send you a .zexp file (or anyone else who asks :).
Please do!
Having said all this, I'm sure XSLT may be suited better to this kind of task, as it's specifically designed to do such. But DTML isn't bad at all, and, if you know Zope, it's not hard to whip something up (or change how the rendering works).
I agree. I just objected to the implication that Digital Creations had made something both simpler and more powerful for XML rendering than XSLT. It is probably simpler for simple problems and more powerful for really hard problems but in the vast middle ground it is not as optimized. Paul Prescod
At 10:38 am +0200 23/8/99, Martijn Faassen wrote:
I've been watching the XML-L and XML-DEV lists for, oh 18 months now. There have been announcements of rendering XML into HTML etc on the fly, yes. But the solutions offered have always been too clunky for me (talk of XSL and Java servlets and *much* more arcane stuff flew around and through the list and my head for many moons).
I know next to nothing about XSL and Java servlets. I'd like to study XSL sometime, is it really that arcane? I read something about DC going to fit XSL into Zope, so I'm curious about it.
I initially got turned off by some of the pontificating on the XML lists (discussions of XSL, XSLT, XSL FOs - just seemed too complex to me). It seemed to me like people were investigating things from a research angle and not from an implementation viewpoint (which is ok, but I wanted implementations). Having said that, recent posts on XML-DEV, imply that things may be simpler than I thought - I won't post the example I *did* have, as this is a Zope list, not an XML list! :). That, along with the fact that the XMLDocument product works well and DC have mentioned something about XSL too, is pretty good news. I wouldn't expect anything big to happen in that arena until Zope 2.1 is out (before people go looking, Zope 2.1 *does not exist*, DC have said they are feature freezing 2.0 and making it stable, before embarking on new functionality). tone. ------ Dr Tony McDonald, FMCC, Networked Learning Environments Project http://nle.ncl.ac.uk/ The Medical School, Newcastle University Tel: +44 191 222 5888 Fingerprint: 3450 876D FA41 B926 D3DD F8C3 F2D0 C3B9 8B38 18A2
participants (5)
-
Evan Simpson -
Martijn Faassen -
Michel Pelletier -
Paul Prescod -
Tony McDonald