[Zope3-dev] Re: One namespace for ZCML

[Martin Aspeli]

Philipp von Weitershausen <philipp <at> weitershausen.de> writes:
 
> > I'm not arguing (here) against refactoring the namespaces in which
> > "core" directives are declared.  I'm arguing against the idea that
> > namespaces are bad in general.
> 
> I'm not arguing that either. I'm just saying that one namespace is
> sufficient.

It may be sufficient for Zope itself (I don't know if it is, I haven't reviewed
all current ZCML directives and use cases), but it won't be sufficient for
third-party extension or anything else that wants to use ZCML for its own
purposes, which seemed to be the argument higher up the thread. If I
misunderstood you on that point, please accept my apologies. 
 
> I am *for* declaring XML namespaces. I'm against declaring too many
> pointless namespaces.

Then I misunderstood you earlier. I'm sorry for that.

> 
> >   - "Why does the core use more than one namespace?"  This question
> >     seems legitimate to me:  I think we wanted to allow non-mangled
> >     names for otherwise conflicting directives, e.g. 'browser:view'
> >     and 'xmlrpc:view'.
> 
> Yes. Using namespaces for this is arbitrary, though. We could just as
> well have chosen different names, e.g. browserView and xmlRpcView.

Erm... you can if you want, just use a different xmlns:browserView. It's up to
the person writing the XML file, although conventions are useful.

> > Nope.  You are ignoring the cases which are currently done TTW in Zope2:
> > mailhost configuration, for instance, or caching policies, etc.  If
> > an application wants to add a diretive which makes it possible to
> > configure such policies in ZCML, why should we prevent that?
> 
> Very true, I forgot to mention that use case. But I also never put them
> on my hit list, for exactly the reason you mention: They are about
> policies and configuring code components.
> 
> So, yes, deployers will edit ZCML directives, but on a limited scale.
> Would they configure a DAV namespace adapter? I would think not.

+1

Martin