Berin Loritsch wrote:
That and how is the Cocoon block definition conflicting with Avalon
definition for blocks. I believe there is some conflict, and since
it seems that the Cocoon community doesn't want to have a two way
compatibility going on with Cocoon blocks,
It's not that we don't want only, it's that it doesn't make sense to use a Cocoon block in a generic Avalon container.
In fact the suggestions were to keep a common place but distinguish on DTD, so that future convergence could be easier. If you prefer the more clear-cut solution, I have no problem with it.
I believe Stefano made it pretty clear that he doesn't want to waste time collaborating on the DTD or other block semantics. That's fine, but that also means that you guys are pretty much operating with what should be considered proprietary APIs/packaging requirements. To that end, you should put proprietary information in a proprietary location.
Believe me, it is easier to merge when it is clear what is being merged. When the lines are less clear, you tend to start assuming one side of the equation already does something when it doesn't. Assumptions==bad. I would rather make it painfully clear what is a Cocoon semantic and what is an Avalon semantic so that when the time comes to merge, we can.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin