David Crossley wrote:
Reinhard Poetz wrote:
A simple scenario could be:
Pipeline API + java.net.URL + XML-SAX components
A more advanced scenario could consist of
Pipeline API + Sourceresolve + XML-SAX components + Sitemap Engine
Is "sourceresolve" where the Apache XML Commons Resolver
is hooked up?
no, I was talking about the Excalibur Sourceresolve component.
I would be concerned if our base offering enabled
mis-use of net resources, e.g. processing an xml file
which declares a DTD, causes an extra network trip if
we don't have the xml entity resolver.
Resolving XML entities is important and we will definitly offer solutions for it
in the future too.
Corona, Steven's and my proposal of a Cocoon reimplementation, is about doing
things differently so that Cocoon becomes easily embeddable and reuseable from
within as many environments as possible. We think that a "layered design" is the
key to achive this goal. When you put all layers together, the result (= a web
application framework) should be nearly[1] as powerful as that what we have today.
For that purpose Steven and I have also started to reimplement existing concepts
instead of doing everything from the scratch. First, we believe that many of the
existing concepts are good as they are and second, this makes it easier for
others to chime in because if you see Corona as a black box, it should (more or
less) provide the same results as 2.x.
HTH
[1] The only exceptions are things that we want to remove, e.g. sub sitemaps
etc. -> see the Micro-Cocoon discussion:
http://marc.info/?l=xml-cocoon-dev&m=119903256406947&w=2
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair [EMAIL PROTECTED]
_________________________________________________________________________
