[Zope3-dev] One namespace for ZCML

Martijn Faassen faassen at infrae.com
Wed Feb 15 11:01:21 EST 2006

Philipp von Weitershausen wrote:
> Martijn Faassen wrote:
>>* a way to register an XSLT renderer.
>>* registering XML importers and exporters.
> These two immediately triggered "adapter" in my mind :).

XSLT renderer may be a view, that's how we use them now. I think it's a 
candidate for a fairly easy transition to Zope 3 style concepts, in fact.

There are subtleties with XML importers that don't really map to 
adapters directly, at least not in a simple way - you want to register 
different importers for certain XML tags.

> It's important, though, that we do try to
> find a good match between the Zope 3 ways of doing things and the
> historical baggage. In Zope 3 we have developed a nice way of looking at
> things and fit them into very simple concepts. It should be preserved.

Sure, but I want my silva namespace so I don't pollute the Zope 3 space. 
:) Same reason I'm happy with the five namespace.

> Btw, I find it a bit scary that you're trying to replace an install
> method with a lot of ZCML directives. I'm not sure I would welcome a
> procedure expressed through configuration. It seems like some of these
> problems are better tucked away using a deployment framework like
> GenericSetup. But then again, I'm not really familiar with Silva and
> that install.py thing.

Silva's 'install.py' does a lot of stuff that really should be 
declaration, not procedure. Registering metadata sets for content types, 
registering views, etc, etc. Then extensions to Silva also do the same 
thing. GenericSetup would make sense for some of it, but I suspect 
fairly little, except of course that right now lots of Silva's 
configuration, often unnecessarily, ends up in the ZODB.

>>I put in a smiley, but I'm serious about the underlying problem of
>>exposing a lot of long dotted names into Python modules into ZCML.
> No worries, I got the tone of the message. However, to every satire
> there's a true core message, as you're pointing out yourself. I too am
> concerned, but I also think that because dotted names actually have a
> meaning, they might be handier in the end than cryptic short forms.
> And then there's also the point of intrinsic information of a component
> that we're currently putting into ZCML but are starting to put into
> Python. I has already reduced the amount of dotted names necessary.

Yes, I saw that point of yours in another thread replying to me there, 
and I think that's a very good point. Anyway, in my attitude to ZCML I'm 
for piecemeal evolution right now - I don't think ruthless refactoring 
is really necessary, but we can get quite ruthless on certain directives 
or attributes of certain directives.

>>I wonder whether we can do things to make this look simpler. If the
>>dotted names were not hiding in attributes but in element content, we
>>could come up with some kind of XML vocabulary for them, even. :)
> At least it would give you the possibility to define and use XML
> entities for them :). Seriously, though, I wouldn't be sure of my vote
> for a system like that. As said, dotted names have a meaningful
> background (Python import paths). Abbreviations most likely don't. I
> rather build something that makes sense than one that relies on too many
> naming conventions...

Agreed; this needs to be thought through carefully. We don't want to 
replace dotted names with a lot of shorter stuff you need to memorize 
anyway, either. It needs to be somehow predictable, and perhaps dotted 
names are the best we can do, if we can at least get rid of some of them 
and move it into Python. It's just an interesting area to think about.

>>>I just think having to declare 3 to 5 different
>>>namespaces on the top of the file of which some have no apparent
>>>meaning or distinction seems like clutter to me.
>>Some indeed have no apparent meaning and distinction; I think
>>zcml:condition could be safely folded into Zope's namespace. When I see
>>apidoc or wfmc I can identify what is involved, though - possibly they
>>can still be eliminated but they definitely have meaning to me.
>>In the documentlibrary, so far we've only used two namespaces, zope and
>>browser. In schooltool, more namespace happen: apidoc, wfmc, i18n and
>>zcml. I think eliminating the 'zcml' namespace would get us down to 2 or
>>less declarations for most .zcml files.
> I think the 'zcml' namespace should be separate from the 'zope' one
> because 'zcml' is meta-ish whereas 'zope' is about actual and factual
> directives. I would rather see 'meta' directives folded into 'zcml'
> (like I propose in the proposal).

zope:include and friends are meta-ish too though. Moving those into a 
separate namespace would suddenly grow the amount of namespaces necessary.

Perhaps folding the meta namespace (+ zcml) into zope is actually 
something we can explore. The meta namespace should be a fairly solid 
XML vocabulary after all.

>>>Note that I absolutely see the necessity for namespace declarations. For
>>>example, I would like to see ZPT require the declaration of TAL, METAL
>>>I18N namespaces. Note that there the entire namespace story is different.
>>>There they are used for what I think namespaces are intended, separating
>>>several XML models (e.g. the HTML model from the additional
>>>TAL/METAL/I18N model).
>>I think Zope 3 extensions extend the Zope 3 XML model. They're less
>>different than combining XHTML with TAL, but I still see a core
>>vocabulary with potentially arbitrary extensions.
> Seems like a good distinction, though it also would suggest that perhaps
> everything living in 'zope.*' packages should only use one namespace
> ('zope'), just like other packages would use other namespaces.
> *That* would be a ZCML namespace policy I would be comfortable with.

I am not saying I agree with this proposal, but it's a direction I'd not 
be against exploring. This means though that certain Zope extensions 
that really add extension specific namespaces, such as email, need to be 
removed from the Zope 3 core; I don't want the email extension specific 
directives to end up in the general component configuration vocabulary. 
Same with the workflow story.

This ties into the whole 'what is a Zope 3 extension and what is core' 
discussion. It could be that if we move stuff into extensions you might 
closer to what want you want while nothing changes to ZCML, if at least 
you install these zope extensions first. :)



More information about the Zope3-dev mailing list