On Tuesday, Sep 23, 2003, at 14:10 Europe/Rome, Bertrand Delacretaz wrote:
Le Mardi, 23 sep 2003, � 14:03 Europe/Zurich, Stefano Mazzocchi a �crit :...Yeah, well, too bad we already have something along 20 namespaces who already don't follow that convention.
We could for blocks at least, couldn't we?
using
http://apache.org/cocoon/block/pdf/namespaces/foo/.1.0
instead of
http://apache.org/cocoon/blocks/pdf/foo/.1.0
yes, but there are a few things I dislike about that:
1) the URI space of blocks id and namespaces get mixed
2) the above seems to suggest that block implementors are freed from the usual namespace-creation policies under cocoon.
Sylvain pointed out the case where a namespace needs to be associated to a particular block, but the more I think about this, the more I think this is wrong and shouldn't happen.
I have no problems if one 'certified' cocoon block uses a particular namespace that had to create because nobody else provides it, but this namespace should *NOT* be associated with that block anyhow.
I would go as far as saying that is should *NOT* be allowed to have a namespace associated to a particular block or that contains the word "block" inside, unless is a namespace that about *blocks in general* (say the namespace of the block wiring markup, for example)
With this restriction, we can use one single scheme and have
http://apache.org/cocoon/ -> Cocoon URI prefix
http://apache.org/cocoon/block/ -> Cocoon Block-ID URI prefix
where "namespaces" have to belong to the cocoon URI prefix but *NOT* on the Cocoon Block-ID URI prefix.
This would remove the need of a duplicate URI prefix http://cocoon.apache.org/cocoon.
Thoughts?
-- Stefano.
