Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Message-ID: <E171BBFA0ABED31184F90060B0571C4C6230@oil-law61.oil-law.com>
From: Paul Lamb <paul@oil-law.com>
To: "'cocoon-dev@xml.apache.org'" <cocoon-dev@xml.apache.org>
Subject: RE: [RT] i18n in Cocoon and language independent semantic context
	s
Date: Mon, 12 Jun 2000 10:04:33 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> Paul Lamb wrote:
> >=20
> > BTW, Stephano, what's your native language?=20
>=20
> Oh, gee, this is a lost cause... my name is Stefano, pronounced as
> "St=E9h-fan-o" NOT "Ste-ph=E0-no", grrrr
>=20

Looks like yesterday wasn't a good day for spelling your name, as I
destroyed your first name and someone else the last. I do apologize, I =
have
a good friend here who's name is Stephan, who is often close enough =
nearby
to physically knock me up-side the head when I get it wrong.

[snip]
> >=20
> > Or, "How can we design both the sitemap and the engine to expect
> > evolutionary changes? What about revolutionary ones?"
>=20
> Ouch, touched a nerve here.

Didn't mean to, you've been asking these types of questions a lot =
lately,
and I think it's good thing. I've been in the process of moving two =
sites to
their third generation of implementation and I really remember thinking
about this during the last set of changes. But now it seems that I =
either
really got it right or I really got it wrong, not much in between.


[snip]
> What's the best way to integrate it? Apache should become a native
> version of Cocoon? Should Tomcat? Should Catalina?
>=20
> I have no idea, but I'm doing something.
>=20
> I do plan to use Catalina-specific hooks when it becomes mainstream.
> (Catalina is the codename for what many believe it will be Tomcat =
4.0)
> This would allow us to use sitemap.xml "instead" of web.xml for
> cocoon-based applications.
>=20
[snip]
> > The first thought that comes to=20
> mind here, is
> > something like a valve pattern, like Craig's done with catalina.
>=20
> Exactly.

This brings up one of the things I like about catalina and has =
influenced my
thoughts on cocoon2 lately. Catalina on one hand provides a very clean
implementation of a webserver/serlvet engine; but on the other provides =
a
very clean path to replace, extend and/or enhance existing pieces of =
it.
Granted, 80% of those downloading it, will never add a single line of =
code
to catalina itself; but for the 20% that need to, it is really great to =
work
with.

My thoughts on the sitemap are the same way. It would be best to create =
a
map that served 80% of those downloading it, in an easy and direct =
manner.
But, it should also allow others enought rope to hang themselves =
properly.

[snip]
> Hmmm, this will create pain in Cocoon users that need to choose what
> sitemap schema to use before having played with the technology.
>=20
> I think of this more as a "last resort" type of thing and mainly for
> ourselfs developers: to simplify development of the sitemap=20
> interpreter.
> =20

While I like the idea that there may be multiple sitemap =
implementations, I
_VERY_ much agree that there needs to be a _SINGLE_ standard default =
one.
This isn't much different than what we talked about above with =
Catalina.
Catalina will distribute based around a web.xml for the forseeable =
future;
but due to its design, I could create a version that loads sitemap.xml =
using
my code instead by changing one line in server.xml.

This also brings up another point. Doesn't this mean that we're now =
going to
have both a cocoon.xconf and sitemap.xml? Aren't we going to need a way =
to
get the parts of the engine initialized before loading the sitemap.

This also comes up, because it seems from the really basic questions =
that
come thru the list that it might be useful to check during our servlet =
init
function to make certain that specific jars are available and their =
version
info--xerces provides this, I'm not sure about xalan. As well as a =
basic
check that xerces is loaded before parser.jar. I'd even be willing to =
write
this for both cocoon2 and cocoon1.

Paul Lamb