[Zope-dev] XML Roadmap (Fwd: [XML-SIG] Hello)

[Amos Latteier]

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