[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?
> 
> 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.

>>>Why is it then recommended that third-party packages use their own
>>>namespaces, even though they might only have browser-related directives
>>>to register...?
> 
> 
> Third-party packages which don't define new directives don't need their
> own namespaces.  If, for instance, Plone adds a "plone:view" directive
> which is nothing more than a no-op wrapper around 'browser:view', that
> would be a Bad Thing (TM).  If, however, they add a 'plone:frobnatz'
> directive which does something magical and outside the scope of the Zope
> core, and document how to use it when setting up Plone, that would be a
> Good Thing, especially if it kept people from changing "site policy" by
> customizing software.

Sure, I don't mind the policy-changing frobnatz. After all, that's what
ZCML is for, defining and adjusting policy.

>>>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.
> 
> 
> ZCML *must* support extensibility, and therefore must continue to allow
> packages to register their own namespaces (unless we abandon XML
> altogether).

I don't see how that conclusion works.

It seems like you think namespaces are needed for extensibility. They
are not. We can add directives to existing namespaces just fine.

XML Namespaces are useful for extending existing XML dialects with stuff
from others. E.g. embedding SVG into HTML, adding TAL/METAL to HTML, and
the like. The way ZCML uses namespaces isn't even half-way compatible
with that. For example, I couldn't add inline-documentation to ZCML
unless I configured no-op directives for my particular documentation
elements, just so that the ZCML machinery wouldn't complain it
encountered unknown "directives". Why would it think that they are
directives?

I can add inline-documentation to XSL or, heck, OpenDocument just fine.
ZCML wants to be XML but it's weird about it.

> Otherwise, we give up the ability to check that a given
> directive can actually be interpreted at all, which would be a Bad Thing.

Huh?

>>>>- 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...
> 
> 
> Just note that being able to extend the configuration language from
> non-core code is an important use case.

I agree it is.

>>>>  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.
> 
> 
> A lot of the feedback seemed to be along the lines of:
> 
>   - "ZCML sux -- I won't use Zope3 until it is gone!"  They weren't
>     gonna use it anyway.

...

>   - "Why do I have to declare the namespaces?" (XML haters, for the most
>     part;  note that I am not an XML fanboy myself).

I am *for* declaring XML namespaces. I'm against declaring too many
pointless namespaces.

>   - "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.

>>>>- 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)
> 
> 
> 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.

>>>>- 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.
> 
> The origin of the "dead chicken" meme, was Guido (and others) who
> objected to the mistake-prone typing required by the earliest set of
> directievs we had;  Guido called them "dead chickens".

If you see any dead chicken around the corner in my Reducing the amount
fo ZCML directives proposal, please let me know in detail.

Philipp