Stephen, >>> so perhaps Peter can clarify where the >>> differences for alternate container should be apparent. >>> >> >> >> No you summed it up well. All the containers I will work on will have >> a common model. Currently this is evolving but getting closer to set >> and is basically defined in containerkit project. > > > Umm, sounds familiar - a common model defined within a scope that > enabled YOU personally to veto anything that YOU personally don't > like. Reality check - containerkit doesn't work for Merlin, doesn't > work for Fortress. Do you indent to deal with this or simply discount > the rest of us as irrelevant to you view of the world ?
With respect to Peter, the .xinfo contract was not the product of a rushed design. Stephen, please pull back from personal attack. >> It would be great to see other containers reusing the shared >> components and this will happen in time. My initial motivation was to >> enable myrmidon, and cocoon sharing with Phoenix sharing as a fringe >> benefit. >> >> Hence in the future BlockInfo will probably be deprecated and >> replaced with the more comprehensive ComponentInfo. > Are we talking BlockInfo.java here? Or .xinfo? > [...] > [...] The API is not defined by the DTD. Please - let's focus on one > layer at a time and keep the discussion cleanly focussed on the issues > at hand. > > The objective is one DTD that address all of the requirements - not > just yours. With respect, if the DTD allows elements and attributes that Phoenix cannot use, then there is a possibility that the block developer might avail of those features and thus, yes it is part of the API. - Paul -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
