Shane Hathaway wrote:
I think I'm starting to grasp the XML division among Zope developers.
 ZConfig schema definitions use a conventional style of XML with
deeply nested elements, text nodes, and no namespaces, while ZCML
uses its own style with minimal nesting, many attributes, and many

ZCML doesn't have that many namespaces in practice. Even large practical
Zope 3 applications tend to only (or 95%) use the zope and browser namespaces. At least, that's my experience in building a large application.

I think many of the other namespaces introduced by Zope 3 are at least
in part actually more useful as local configuration and not global ZCML
configuration -- I'm thinking about the mail namespace for instance,
where really one often would like to configure the smtp server to use
either through the web, or through a global application-level
configuration file, but *not* in ZCML. The SMTP server an application
server is to use is not something I want to check into svn, after all.

Five actually adds a 'five' namespace, which I think is very useful -- it clearly marks which directives are only there for Zope 2 and thus you cannot expect them to work in Zope 3. Not having namespaces would make this a lot harder to mark, and the temptation would exist to mangle namespaces into the names by using prefixes and the like.

Many of us have a strong preference for one style or the other and
we're perplexed that others would actually prefer their crazy style.

I remember that Jim once presented two XML samples and asked which
one was more readable.  I preferred many elements over many
attributes.  He preferred the opposite.  I thought he was crazy, and
as I recall, he thought I was crazy, too. :-)

My hunch is that I think ZCML could do with a few more elements and text nodes. I don't think matters as they stand are crazy though.

This division probably exists because there is no widely accepted
"Zen of XML".

There is a bunch of material, and I think some ideas about XML design are probably more widespread than one would guess at a first glance, but it's true that it's not as well established as "proper Python code" (even though there's a lot of difference in opinion about that too, and it evolves).

Anyway, the semantic effort to remove whole directives and move that functionality into Python code, and to remove particular attributes and move that information to Python code, is valuable also to simplify ZCML syntactically. I think after this process of reducing ZCML semantically is done, we have a clearer picture on what possible alternative syntaxes (XML or non-XML) for ZCML might be sensible.


Zope3-dev mailing list

Reply via email to