cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Squaring the sitemap circle...
Date Wed, 24 May 2000 22:47:37 GMT

Cocoon1 presents great ideas but fails to provide simple and effective
patterns to make they work as they should. The greatest problem was
identified in the lack of centralized configuration for resource
programming and administration.

This resource is now simply referred to as the "sitemap".

The sitemap requires lots of structure, for this reason, we identified
the XML syntax as the best to handle such types of documents.

The sitemap is therefore an XML document.

Next step was to create a schema for that document. Note, however, that
validation as DTD or XMLSchema outline is not of our concern since
Cocoon itself will provide the logic to validate the sitemap.

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
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 size
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 mapping
need, even for
8) basic web-serving functionalities (redirection, error pages,
authentication) should be provided
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 ┬░semantic resources┬░
12) sitemaps should allow raw resources to be found using URI
13) sitemaps should be flexible enought to allow a complete web site to
be built with Cocoon

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.

Implementation complexity was of minimal importance, but I kept an eye
on speed and I believe no algorithmical limitations on speed exist.

Please, see a sitemap example attached.

I didn't place any comment because the sitemap should be selfexplaining.
If not, I made design mistakes and you feedback will allow further

Almost everything changes since the sitemap that Pier implemented in the
current xml-cocoon2 CVS branch. I believe the changes are so radical
will require a complete rewrite of the sitemap part, but aiming to back
compatibility was simply impossible given the different goals and

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 new
ones or overrule inherited ones.
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
4) the notion of matching rules is embedded into the schema.
5) the notion of components and component typing is embedded into the
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 is
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
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.

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.

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.

I do not consider _any_ of the parts carved in stone, but let's try not
to enlarge the requirement goals too much or we'll never be able to
implement it :)

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
View raw message