[Zope3-dev] Re: One namespace for ZCML

[Philipp von Weitershausen]

Tres Seaver wrote:
>  - The opposition to namespace declarations is whiny, as they are the
>    standard way to make XML extensible.  Unless we are going to quit
>    using XML, outlawing namespaces would be equivalent to saying, "you
>    may not extend ZCML";  I don't think we are smart enough to make that
>    ukase.  I think the Last Law of Python according to the Prophet
>    Peters obtains here as well.

I'm neither trying to follow the whiny people who detest XML and
therefore ZCML nor am I trying to make ZCML not extensible. That said, I
think that ZCML's usage of namespace is quite arbitrary. Why is browser
and mail-related stuff on its own namespace but security-related stuff
not? Why is it then recommended that third-party packages use their own
namespaces, even though they might only have browser-related directives
to register...?

I don't really see the point in ZCML's using namespaces. What good do
they provide? Seriously, is it just the prefix? Well, we don't need the
namespaces for that.

>  - Note that the non-XML language also used by Zope (ZConfig) has its
>    own extensibility mechanism:  in fact, Fred and I made it possible
>    in November for Zope2 products to register their own schemas for
>    those extensions, which was a blocker for moving some configuration
>    out of software.

I'm not sure what to do with this info...

>  - I don't want to encourage people to do configuration in Python:

Rest assured neither do I.

>    we have moved away from that *on purpose* in Zope, and I don't see
>    a reason to go back.  Directives which make it possible to change
>    policy decisions without touching software are a Good Thing.  I think
>    that letting people who spend their days up to the elbows in the
>    software make choices here skews the picture:  we *want* people to
>    be able to change the behavior of the system in controlled ways
>    without having to modify software;  I would prefer to hear feedback
>    from non-core-developers before going further with the "ZCML delenda
>    est" thread.

I have heard such feedback, otherwise I wouldn't have taken the time to
write the proposal. I've also heard positive feedback on this particular
matter (reducing ZCML namespaces to one). Again, I wouldn't have brought
it up otherwise.

>  - The "application vs plugin" discussion is probably germane to this
>    issue, as well:  a user who is deploying a single application is
>    acutally *more* likely to define and use convenience directives
>    which reduce the amount of effort required to change policy than
>    the generic appserver-with-plugins configuraiton.  Removing the
>    ability to create such convenience declarations makes it harder
>    for those developers.

This belongs in the other thread, really. But here it goes anyway:

I'm not convinced that people who deploy apps will actually go as deep
as editing package ZCML, or even overrides for that matter. I would
rather imagine they turn ZCML features on or off (which would then turn
on or off ZCML directives via zcml:condition)

>  - Many of the objected-to directives exist precisely because people
>    did not want to type the much more verbose equivalents which were
>    the original, "cleaner" spellings.

Or perhaps people just thought that people wouldn't want to type in some
extra stuff. Because I think they do if it helps them remember and
understand better.

Philipp