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

[Vladimir Marangozov]

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