Hash: SHA1

Philipp von Weitershausen wrote:

> Tres Seaver wrote:


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

Not if you need to mangle names to avoid clashes.


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

I don't want to encourage third-party applications to inject their names
into "stock" namespaces, because then I can't safely mix unrelated
third-party packages without chasing down conflicts.

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

I don't want DocBook in my ZCML, personally.  "De gustibus" again.  At
the moment, ZCML does assume that all elements in a ZCML file belong to
it.  If you wanted to add DocBook to your ZCML, then you could add a
meta.zcml file which registered faux handlers for the docbook elements;
 you might also add a directive to ZCML which instructed it to ignore
all nodes from a given namespace.

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

Right now, ZCML does a syntax check on the files it processes, and barfs
on elements it doesn't understand.  I don't want to lose that check if
the only benefit is the ability to inline "foreign" elements.  Again, I
wouldn't mind some syntax which told ZCML to ignore names from
particular "foreign" namespaces.


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

Now we are getting close to 'de gustibus' territory.  Your proposal
seems to make a claim that we don't / won't need more than one
namespace, while the ones we have are there because people were trying
to avoid name clashes.  There may be some which could be refactored
away, but I don't think that is the same point the proposl si trying to

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

I don't think that was arbitrary all:  we use namespaces *as they are
designed* here, to allow people to use "natural" names for things
without worrying whethere they clash with names which are equally
natural in another domain.

This is why Python has namespaces, too:

 >>> import this
 Namespaces are one honking great idea -- let's do more of those!

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

They might, if they were supplying additional properties through DAV
which the "stock" adapters don't support.

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

I'm just trying to point out that we added "convenience" directives in
order to address earlier usability complaints about the (theoretically
cleaner) original directive set.

- --
Tres Seaver          +1 202-558-7113          [EMAIL PROTECTED]
Palladion Software   "Excellence by Design"    http://palladion.com
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to