XML Roadmap (Fwd: [XML-SIG] Hello)
I'm forwarding a message (below) from the Python XML-SIG list, which raises a few questions about Zope's XML plans. They are interesting questions, which I imagine Digital Creations has already considered, but I don't recall seeing any specific discussion here. I'm sure the XML-SIG folks will be able to address some of these questions, but the DC-related ones should probably come "from the horse's mouth"? ---------- ## Forwarded Message ## ---------- Subject: [XML-SIG] Hello Date: Fri, 29 Oct 1999 11:45:32 +0100 (NFT) From: Vladimir Marangozov <Vladimir.Marangozov@inrialpes.fr> Hi all, I'm relatively new to the XML world (which is not the case for Python) as well as the W3C standardization efforts in this area, but as a benevolent INRIA webmaster I have to jump in, so I joined this sig. (finally! :-) and I plan to stay for a while... ;-) I have some comments and a couple of questions that I hope you'll be able to answer. I realize that the information exists somewhere, or I can analyse the code to see what's done or doable and what's not, but I'd better refer to you as more experienced in this area and save some precious time. I'm building a medium-sized website (approx. 150 pages) and I already have some content and a relatively complex layout, all written in valid HTML 4 almost by hand <ouch!>. Continuing this way, as you know, is a dead end. I have been told (and more precisely, the W3C people working here) that I have to put my content in XML, then use XSLT to transform my content and generate the HTML layout. This way, if I want to make radical changes to the layout or the output documents, the only thing I'll have to modify is the transormation rules. I guess that this is not the only solution for my task, but I'd better follow their advice in the long run. So, as a Python addict, I made a quick tour on the Web to see what Python tools exist for the job. The good news is that the XML-SIG has already packaged the low-level machinery of XML -- a very nice piece of work! Another good news is that the FourThought guys have released recently parts of their 4Suite, including the XSLT and XPath packages. I haven't tried them yet, so I'm not in a position to comment whether the implemented subset of the W3C recommendation (PR-xslt-19991008) will suffice for my task. (I can only regret that James Clark's XT was written in Java, and not in Python. I'll tell Vincent Quint to convert him ;-) A third good thing is Zope. I won't comment too much on it because you already know better than me what Zope is and does. What bothers me a little bit in Zope is that I'm not convinced that I can clearly separate content from style. Zope relies on templates, not on transformation rules. So, I wonder whether I really have today the Python basic bricks to perform the following: 0) Define my DTD and deduce the user-friendly forms for 1). 1) Fill my content via user-friendly forms (a la Zope) 2) This content is wrapped and stored in XML. 3) The XML files are processed according to my stylesheets and the XSLT processor. 4) The formatted result (currently in valid HTML 4.0) shines on my screen (when I click on Zope's preview, for example) Basically, I'd like to "plug" the XML/XSLT part in the Zope site-building process. Fundamentally, Zope's DTML resembles XSLT, but as an INRIA employee, I tend to prefer XSLT and the standards my colleages are working on ;-). In the end, is this doable? Are there any missing parts or tools in this chain? I wish that the people at DC consider a strategical move for Zope, so that this excellent product incorporates (or is interfaced with) the W3C standards. Damn, even the examples in Zope are not in valid HTML! DTML is good (it was developped before the current standards), but a shift or a bidirectional converter DTML<->XSL/T would be a major win. Whether this is doable is another story. I don't know too much of the details yet, but I plan to get at full speed shortly :-) -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 _______________________________________________ XML-SIG maillist - XML-SIG@python.org http://www.python.org/mailman/listinfo/xml-sig -------------------------------------------------------
Patrick Phalen wrote:
Basically, I'd like to "plug" the XML/XSLT part in the Zope site-building process. Fundamentally, Zope's DTML resembles XSLT, but as an INRIA employee, I tend to prefer XSLT and the standards my colleages are working on ;-).
What a coindcidence!
In the end, is this doable? Are there any missing parts or tools in this chain?
Yep. I'm currently prototyping a new component for Zope called MFI (Multi-Format Interface, I needed a good TLA). If you can follow my stream of conciousness, MFI realizes two very cool ideas: 1) Objects that want to contain 'content' in various 'formats' 2) Objects that want to override their behavior at 'call time' (ie when viewed by the browser) A brief description of the achetecture is: Objects that wish to use the MFI subclass two classes, MFI and Behavior (there is another class, Cache, which realizes smart caching with objects, but that's strictly a performance issue). MFI provides the framework for objects to use one of any pluggable type of format. Currently, I am realizing 4 formats: NULL (does nothing to the content) HTML (does nothing for now, but in the future may parse out HTML properties/entities) STX (structured text, it's a Zope thing) XML (parses content into a DOM tree) So there are two actions done for each format type: At 'format' time, the content is parsed and transformed into 'formatted content' for NULL, HTML and STX, this currently does no parsing. XML is parsed into a DOM tree. At 'call' time, the content is returned to the caller (typically a browser) in a default way, NULL and HTML do nothing, STX renders the structured text into HTML, and XML is returned to the browser as XML. This is the 'default behavior'. All 'formatters' can specify both the 'format' and 'call' actions. The call action specified by a format is the default behavior. Now, an MFI objects that also subclasses Behavior can specify a number of plugable behaviors that replace the 'default behavior'. If no pluggable behavior is specified, then the default behavior for the format is used. Currently, there is only one pluggable behavior, DTML Method. It would be trivial however to include any other method type, like External Method, PythonMethod (by Evan Simpson) or, as I see it, an XSLTMethod (that only makes sense in the context of an MFI object that uses a format that results in a DOM tree-like object). So, here is a scenario I think you'll like: Create an MFI document and fill it with XML, specify the format as 'XML'. Select 'XSLTMethod' as the pluggable behavior, and type your XSLT code into the behavior text area. Now: When the object is 'called' (from a browser, let's say) the XML content is transformed by the XSLT into whatever you want. You could also have specified 'DTMLMethod' and written some DTML that called DOM methods etc. The beauty of all this is that it's absolutly extesable and fits nicely into the Zope framework, for example, methods can be acquired by behavior just like other methods in Zope can acquire each other, therefore site-wide behavior can be automaticly specified and overridden on a behavior by behavior basis. Entire behavior frameworks can be written in a combination of languages (DTML, XSLT, python) and mixed and matched into a variety of content in a combination of formats (plain text, HTML, stx, XML). -Michel
Seems like I'll start zoping, at least temporarily, intrigued by Michael's reply to my original message sent to the XML-SIG. Hello Zope World! Michel Pelletier wrote:
[me]
Basically, I'd like to "plug" the XML/XSLT part in the Zope site-building process. Fundamentally, Zope's DTML resembles XSLT, but as an INRIA employee, I tend to prefer XSLT and the standards my colleages are working on ;-).
What a coindcidence!
In the end, is this doable? Are there any missing parts or tools in this chain?
Yep. I'm currently prototyping a new component for Zope called MFI (Multi-Format Interface, I needed a good TLA). If you can follow my stream of conciousness, MFI realizes two very cool ideas:
[snip] Sounds promizing. I'm still a Zope newbie, but I'm willing to discuss a couple of things here (I hope this is the right forum). Note that the XSLT transformations of the XML content I was referring to is usually a one time process (for now). From your message, it sounds like the XML processing will occur on object invocation (on demand). Being able to handle this dynamically is a cool feature, but it could be penalizing in some circumstances regarding performance (if the end result is not cached, of course). Next, I have two major thingies in my wishlist for Zope and I'd be happy to contribute something as time permits. 1. This is a major wish, regading the object's content. It seems from the examples provided with the distribution that I have to provide the content in the format I'm willing it to be (in my case -- XML). Why not reusing the Zope interface for filling intelligently my content, being guided by Zope according to my DTD? The DTD defines the grammar of my content, so theoretically it should be possible, given a DTD to generate on the fly the input forms of the elements I have to fill in, and add/remove elements and attributed according to that DTD. This will ensure that my content is well-formed -- a major requirement in the Web world! For example, if I have the following simplified DTD: <!ELEMENT ADDRBOOK (PERSON*)> <!ELEMENT PERSON (NAME, ADDRESS, PHONE*)> <!ELEMENT NAME (#PCDATA)> <!ELEMENT ADDRESS (#PCDATA)> <!ELEMENT PHONE (#PCDATA)> Zope could generate input forms for me, containing the fields NAME, ADDRESS and PHONE, and an option allowing me to add several fields of the PHONE element. And only these! No other forms should be possible. This will ensure that the document is well-formed according to that DTD. This resembles very much the user-interfaces people are using for filling and consulting database records. Actually, it seems that Zope has only 1 DTD for an object, which goes along these lines: <!ELEMENT CONTENT (#PCDATA)> Extrapolate this idea 1 step further, and it would be possible to define with Zope's help even the DTD! :-) The DTDs for almost all Web formats exist, notably the ones which are of major interest nowadays for Web developers -- HTML 4.0 Transitional, and HTML 4.0 Strict. If all this already exists, (don't forget that I'm a Zope newbie :-), then just point me to the feature and ignore the above. 2. The second wish is the Presentation aspect I've talked about previously. The format of the content delivery should be completely decoupled from the content. This is why all these new standards about XSL/T are about. In the forthcoming years, content delivery will be formatted dynamically according to the client's device. If I browse the Web with Netscape v.3, the content will be delivered in HTML v.3; if I have an XML-ready version of IE, the content will be delivered in XML; if I have a mobile device, the content will be transformed according to the limited presentation abilities of my device, etc, etc, not to mention that the same content should be accessible for people with disabilities... That's why content formatting, as a separate step, is so important. I'm glad to see that there is ongoing work in this direction. 3. Minor thingie: If the two points above were reality, it would be possible to customize Zope's look and feel itself! For instance, it's important for me to set-up a Web building environment for INRIA, where everything is in french, so that people designing their respective portions of the web space understand what's going on. So, to end up with something more optimistic ;-), I think that the next Zope release should contain at least valid HTML 4.0 Transitional. You can go to http://validator.w3.org for a convenient service on this. I'd be happy to start looking at the source and the templates, and correct this aspect of Zope. The second thing I'm volunteering for now is to translate all user messages to french and try to decouple the messages from the code. This would already be an improvement. Others could provide a translation for other languages. And don't forget -- I'm still a Zope newbie, so if the feature already exists, just point me to it and ignore my rabling :-) Later, -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252
Vladimir Marangozov wrote:
So, to end up with something more optimistic ;-), I think that the next Zope release should contain at least valid HTML 4.0 Transitional. You can go to http://validator.w3.org for a convenient service on this. I'd be happy to start looking at the source and the templates, and correct this aspect of Zope.
Please do!
The second thing I'm volunteering for now is to translate all user messages to french and try to decouple the messages from the code. This would already be an improvement. Others could provide a translation for other languages.
Merci!
And don't forget -- I'm still a Zope newbie, so if the feature already exists, just point me to it and ignore my rabling :-)
Sounds like your covering new ground to me... -Michel
At 09:40 PM 10/29/99 +0100, Vladimir Marangozov wrote:
Sounds promizing. I'm still a Zope newbie, but I'm willing to discuss a couple of things here (I hope this is the right forum).
Welcome to Zopeland, Vladimir, we're happy to have your input!
Note that the XSLT transformations of the XML content I was referring to is usually a one time process (for now). From your message, it sounds like the XML processing will occur on object invocation (on demand). Being able to handle this dynamically is a cool feature, but it could be penalizing in some circumstances regarding performance (if the end result is not cached, of course).
Right now, Zope's convention is usually to produce content dynamically with minimal caching. There've been lots of discussions about different ways to introduce caching at different levels in Zope. Maybe it's time to revive these conversations again.
Next, I have two major thingies in my wishlist for Zope and I'd be happy to contribute something as time permits.
1. This is a major wish, regading the object's content. It seems from the examples provided with the distribution that I have to provide the content in the format I'm willing it to be (in my case -- XML). Why not reusing the Zope interface for filling intelligently my content, being guided by Zope according to my DTD? The DTD defines the grammar of my content, so theoretically it should be possible, given a DTD to generate on the fly the input forms of the elements I have to fill in, and add/remove elements and attributed according to that DTD. This will ensure that my content is well-formed -- a major requirement in the Web world!
For example, if I have the following simplified DTD:
<!ELEMENT ADDRBOOK (PERSON*)> <!ELEMENT PERSON (NAME, ADDRESS, PHONE*)> <!ELEMENT NAME (#PCDATA)> <!ELEMENT ADDRESS (#PCDATA)> <!ELEMENT PHONE (#PCDATA)>
Zope could generate input forms for me, containing the fields NAME, ADDRESS and PHONE, and an option allowing me to add several fields of the PHONE element. And only these! No other forms should be possible. This will ensure that the document is well-formed according to that DTD. This resembles very much the user-interfaces people are using for filling and consulting database records.
Wow. So basically you want a through the web validating XML editor ;-) I believe that this would be a complex task. Right now Zope contains a simple property editor which can control adding, changing and deleting typed properties (see OFS/PropertyManager.py). Perhaps this facility could be a building block for a more complex type of editor. One way to think of adapting XML editing to Zope is to think of Elements as Zope objects with properties (attributes and perhaps Text children). Child nodes are Zope subobjects which can be cut and pasted to move them around the DOM tree.
Actually, it seems that Zope has only 1 DTD for an object, which goes along these lines:
<!ELEMENT CONTENT (#PCDATA)>
Extrapolate this idea 1 step further, and it would be possible to define with Zope's help even the DTD! :-)
This actually sounds easier than getting Zope to parse existing DTDs. There is a long range plan to bring ZClasses (through the web defined Zope classes) and XML support closer together. Perhaps defining a ZClass could be thought of as defining a DTD, in the sense the a ZClass defines editing methods and rules for properties (think XML attributes) and subobjects (think child nodes).
2. The second wish is the Presentation aspect I've talked about previously. The format of the content delivery should be completely decoupled from the content. This is why all these new standards about XSL/T are about. In the forthcoming years, content delivery will be formatted dynamically according to the client's device. If I browse the Web with Netscape v.3, the content will be delivered in HTML v.3; if I have an XML-ready version of IE, the content will be delivered in XML; if I have a mobile device, the content will be transformed according to the limited presentation abilities of my device, etc, etc, not to mention that the same content should be accessible for people with disabilities... That's why content formatting, as a separate step, is so important.
I agree. In Zope however, separating these things is often murkier than in the filesystem world. Since Zope uses a object-oriented view content and format are often methods or subobjects. For example many Zope objects have methods to represent themselves in different protocols such as DOM, FTP, etc. Many object's don't have pure content per se.
3. Minor thingie: If the two points above were reality, it would be possible to customize Zope's look and feel itself! For instance, it's important for me to set-up a Web building environment for INRIA, where everything is in french, so that people designing their respective portions of the web space understand what's going on.
I believe that this is/was a Zope internationalization effort. I'm not sure what the status of this project is currently. I think that it may have its own mailing list...
So, to end up with something more optimistic ;-), I think that the next Zope release should contain at least valid HTML 4.0 Transitional. You can go to http://validator.w3.org for a convenient service on this. I'd be happy to start looking at the source and the templates, and correct this aspect of Zope.
This is a good goal; patches are most welcome!
And don't forget -- I'm still a Zope newbie, so if the feature already exists, just point me to it and ignore my rabling :-)
Thanks for your rambling, you're bringing up good points. -Amos
On Fri, 29 Oct 1999, Michel Pelletier wrote: [snip]
Yep. I'm currently prototyping a new component for Zope called MFI (Multi-Format Interface, I needed a good TLA). If you can follow my stream of conciousness, MFI realizes two very cool ideas:
1) Objects that want to contain 'content' in various 'formats'
2) Objects that want to override their behavior at 'call time' (ie when viewed by the browser)
[description snipped] This sounds very similar to XMLWidgets, VisualZope and ZIE. A few extensions to the behaviour system as described by you which may be useful: * Add XMLWidgets Events to allow the Behaviour to be changed via the user clicking on an item in the browser * Add Javascript Behaviour code to allow Events to operate transparently accross the JavaScript/DTML boundary. * You will need a final rendering stage due to problems in Zope namespace conflicts. If you wish to utilise the ID property within an XML document you will need to rename it to CID and apply a text transformation to convert it to ID. * Why not allow multiple behaviours? For example, an XSFT transform to apply corporate styles, a DTML ZDOM transform for custom javascript and a few others to make some objects "Active". For example: <mydoc> <item behaviours="draggable, resizeable, event=GotoPagexx"/> ^^^^^^^^^ inherited from Behaviour objects in the aquisition path </mydoc> Cheers, Anthony Pfrunder
participants (5)
-
Amos Latteier -
Anthony Pfrunder -
Michel Pelletier -
Patrick Phalen -
Vladimir Marangozov