cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: block perspectives
Date Wed, 01 Oct 2003 12:49:47 GMT

On Wednesday, Oct 1, 2003, at 10:33 Europe/Rome, Stephen McConnell 

[big snip]

> Aside from all of that - I have been lurking here off and on for 
> several months - and see overwhelming reasons for collaboration (and 
> equally overwhelming reasons why this could be a bad thing to do).

I want cocoon 2.2 to implement cocoon blocks and I want it finished 
soon, less than 6 months (including the block librarian and all that). 
This doesn't give me much time to spend on discussing details with 
other projects.

I've looked at merlin/meta and I don't think how this can help us in 
the development (yeah, well, maybe steal some classes here and there, 
but the actual implementation is simply too different)

I believe it's much better if cocoon and avalon keep their focus (no 
matter how big the functional overlap is: the goal overlap is very 
small and the community overlap (in terms of active committment) is 
null) and keep working independently.

In the future, when both system are implemented, we'll see how things 
go and potential refactoring might take place.

In order to allow this, the only thing where I do see potential 
collaboration now is the block.xml descriptor schema... because we 
could well change /BLOCK-INF/ to /COB-INF/ but that would make the two 
systems diverge forever.

So, a few questions:

  1) where is the DTD of your block.xml?
  2) is that block.xml an avalon-wide thing or just merlin-related? 
[means: is that shared with Phoenix?]
  3) how open are you/avalon to changes to this DTD?

At the end, if collaboration is not possible, it would still be 
possible, for containers, to react on namespaces to understand the 
different semantics of the markup used (ah, btw, merin's block.xml 
don't use namespaces, that is generally a good future-friendly practice)

> --

View raw message