Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Sender: giacomo
Message-ID: <392D8315.71ADA38A@pwr.ch>
Date: Thu, 25 May 2000 21:46:30 +0200
From: Giacomo Pati <Giacomo.Pati@pwr.ch>
Organization: PWR Organisation & Entwicklung
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: Squaring the sitemap circle...
References: <392C5C09.1FF117DE@apache.org>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Nice work, eh! Here my first comments about your sitemap proposal.

Let' s put your sitemap example into CVS as the
MOST_COMPLETE_SITEMAP_EXAMPLE_WE_ARE_STILL_WORKING_UPON.
The reason is, we have saved it somewhere, it is quite complete as a
reference, we can use it as a base for documentation, maybe something
like the doc for ants build.xml.

Stefano Mazzocchi wrote:
> =

> The following goals were identified as engineering constraints:
> =

> 1) minimal verbosity is of maximum importance
> 2) the schema should be sufficiently expressive to allow learning by
> examples
> 3) sitemap authoring should not require assistive tools
> 4) sitemaps must scale along with the site and should not impose growth=

> limitation to the site as a whole nor limit its administration with siz=
e
> increase.
> 5) sitemaps should contain all the information required to Cocoon to
> generate all the resources that it receives.
> 6) sitemaps should contain information for both dynamic operation as
> well as offline generation
> 7) uri mapping should be powerful enough to allow every possible mappin=
g
> need, even for

'even for' what?
Did I've seen right, _you_ introduce regex?

> 8) basic web-serving functionalities (redirection, error pages,
> authentication) should be provided

Could't we leave authenticatin to the container (servlet engine/web
server) and concentrate on authorisation? It seems to me your sitemap
example reflects only authorisation, right?

> 9) sitemaps should not limit Cocoon's intrinsic modular extendibility
> 10) resources must be matched with all possible state variables, not
> only with URI (http parameters, enviornment variables, server
> parameters, time, etc...)
> 11) sitemaps should embed the notion of =B0semantic resources=B0
> 12) sitemaps should allow raw resources to be found using URI
> identifiers
> 13) sitemaps should be flexible enought to allow a complete web site to=

> be built with Cocoon

Agreed.

> =

> As you see, squaring such a circle is _not_ a trivial task.
> =

> I spent two complete days to write a sitemap that embeds all the points=

> above. There are some weak points (mainly authentication issues) where =
I
> need some feedback, but there are _many_ new design patterns that I
> introduced by simply writing the more elegant schema I would like to
> work with.

See above.

> Several important enhacements were introduces:
> =

> 1) the notion of "sitemap mounting" allows sitemaps to scale with size.=

> 2) the notion of "sitemap cascading" allows mounted sitemaps to
> "inherit" configurations about used components as well as to declare ne=
w
> ones or overrule inherited ones.

Is "sitemap mounting/cascading" shown in the example sitemap (I've
interpreted the mount tag as raw delivery mechanism)

> 3) the use of URI for both file and classes locations allows ISP to
> provide sitemaps were each sitemap can load classes relative from their=

> locations without requiring central changes and allowing management
> parallelization.

Could you further explain (I don't get this)?
=03
> 4) the notion of matching rules is embedded into the schema.
> 5) the notion of components and component typing is embedded into the
> schema.
> 6) the notion of pipeline programmability thru matching components is
> embedded into the schema.
> 7) the use of a special namespace will guarantee evolution capabilities=

> of the schema without compromising back compatibility when the schema i=
s
> finalized.
> 8) the use of internal placeholders for components fragments allows
> reduction of verbosity when a single tree fragment is reused multiple
> times in the sitemap

Could you further explain (I don't get this)?
=03
> 9) the notion of "semantic-source" allows special crawling to be
> executed (XLink harvesting as well as RDF indexing)
> 10) the ability to return HTTP status-codes different that 200 was
> embedded into the <serializer> element.
> 11) the notion of attribute-javabean mapping is assumed when dealing
> with the <match> elements.
> 12) the notion of Cocoon2 configuration databinding is assumed for the
> elements when found inside <components>
> =

> It must be noted that the validation rules CANNOT be isolated from the
> semantics of the logic components that perform the operations, for this=

> reason the sitemap itself cannot be validated unless at sitemap
> interpretation when loading.
> =

> It must be noted that the matching architecture allows for simple
> authentication as well as very complex authentication schemas, due to
> the pluggability of matchers.

Are you realy meaning authentication not authorisation?

> I must say I'm very proud of this, it was a _very_ hard job to make all=

> these fit together, expecially since there is no other software in the
> world that offers the functionality we are offering with this sitemap.

Yes, good job. Looks good, but this is quiet some work to be done!

> =

> Also note that given the ability to mount sitemaps and resources found
> inside jar archives should allow Cocoon to match functionality with
> other systems that are dedicated to web-application generation, but
> still using XML technology as the core.
> =

> Please, take a look and make comments.
> =


Ok, some comments concerninng you example sitemap. =


1. What is the diffrent between ..class=3D"classpath:org... and
=2E..class=3D"classpath://org...?
2. Should we realy introduce regex?
3. If a request-uri matches a mount-uri the request will be satisfied
from the location and basta? Like usual file serving?
4. According to <matcher> component and <match> process element, should
we name the <generator> process element <generate> (and also
<serializer> and <serialize>)?
5. In the example there where two <process> tags with the same uri
(uri=3D=3D"*"). Is this intentional? =


Some word about authentication. This is quiet a complex area ranging
from so called Basic Authentication to full blown PKI User Certificate
Authentication. I sugest to leave this to the server/container.
Authorisation is the act of giving access to authenticated users, as I
understand it.

Giacomo
 =

-- =

PWR GmbH, Organisation & Entwicklung      Tel:   +41 (0)1 856 2202
Giacomo Pati, CTO/CEO                     Fax:   +41 (0)1 856 2201
Hintereichenstrasse 7                     Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen                    Web:   http://www.pwr.ch