This project has retired. For details please refer to its
Attic page
The Sitemap
apache
cocoon
About
Index
Features
News
License
Documentation
Introduction
Tracks
Introduction
First steps
Web publishing
Installation
Intro
System requirements
Updating to version 2.1.5
Jars
Overview
User Guide
User Documentation
Concepts
Overview
Section Home
Example sitemap snippets
Views
Caching
Actions
Matchers and Selectors
Entity Catalogs
MRUMemoryStore
Persistence
StoreJanitor
XML Searching
XML Validation
Databases
Modules
Modules Reference
Redirection
Profiler
Error Handling
Sitemap Components
Generators
Overview
Default
File Generator
Core
Calendar Generator
Directory Generator
File Generator
Imagedirectory Generator
Jx Generator
Linkstatus Generator
MP3directory Generator
Notifying Generator
Request Generator
SessionAttribute Generator
Status Generator
Stream Generator
Xpathdirectory Generator
Optional
Fragment Extractor Generator
HTML Generator
JSP Generator
PHP Generator
Profile Generator
Script Generator
Search Generator
Server Pages Generator
Velocity Generator
Web Service Proxy Generator
XML:DB Collection Generator
XML:DB Generator
Transformers
Overview
Default
XSLT Transformer
Core
Fragment Extractor Transformer
I18n Transformer
JPath Transformer
Log Transformer
Filter Transformer
Read DOM Session Transformer
RoleFilter Transformer
SimpleForm Transformer
SimpleFormInstance Transformer
Write DOM Session Transformer
Xinclude Transformer
Cinclude Transformer
EncodeUrl Transformer
Sourcewriting Transformer
Augment Transformer
JX Template Transformer
XSLT Transformer
Optional
LDAP Transformer
Lexical Transformer
Parser Transformer
Pattern Transformer
Session Transformer
SQL Transformer
Serializers
Overview
Default
HTML Serializer
Core
HTML Serializer
XHTML Serializer
XML Serializer
Text Serializer
WAP/WML Serializer
SVG Serializer
SVG/XML Serializer
SVG/JPEG Serializer
SVG/PNG Serializer
SVG/TIFF Serializer
VRML Serializer
Link Serializer
Zip archive Serializer
Optional
PDF Serializer
PS Serializer
PCL Serializer
HSSF (XLS) Serializer
Matchers
Overview
Default
WildCard URI Matcher
Core
WildCard URI Matcher
WildCard Header Matcher
Optional
Template Matcher
Selectors
Overview
Default
Browser Selector
Core
Browser Selector
Host Selector
Parameter Selector
Request Attribute Selector
Request Method Selector
Request Parameter Selector
Resource Exists Selector
Regular-expression Header Selector
Scratchpad
Date Selector
Actions
Overview
Database
Optional
Sendmail Action
Session Action
Script Action
Readers
Overview
Default
Resource Reader
Core
Image Reader
Resource Reader
Optional
AxisRPC Reader
Database Reader
JSP Reader
Scratchpad
Directory ZIP Archiver
Flow
Introduction
Continuations
How does it work?
Usage
Tutorial
Flowscript
Calling Java
Views
JXTemplate
JPath
Velocity
Cocoon Forms
Basics
Introduction
Sample
Improving the sample
Widgets
form
field
multivaluefield
booleanfield
repeater
output
submit
action
repeater-action
row-action
aggregatefield
upload
messages
imagemap
tree
group/struct
union
class/new
Widget Concepts
Validation
Event Handling
Datatypes
Selection lists
Widget states
Form Publishing
Templating
Section Home
Template Generator
Template Transformer
Generator
XSLT
Binding Framework
Simple XML Binding
API
Javascript (Flowscript)
Java
Form libraries
Ajax
Forms @ Wiki
XSP
Overview
XSP
Section Home
XSP Guide
XSP Internals
XSP Logicsheets
Sessions
Logicsheets
Request
Session
ESQL
Forms
Sendmail
Offline
Overview
Command Line
CLI Configuration
Ant
Cocoon Bean
Developer's Guide
Index
Concepts
Internals
Extending
Avalon
Source Handling
Stores
Using Databases
Parent CM
DELI Quick Start
DELI
Developing Webapps
Overview
Sessions
Session Contexts
Authentication
Section Home
The Authentication Handler
Authenticating a User
User Management
Application Management
Module Management
User Administration
Configuration Summary
Pipeline Patterns
Simple Forms
Portal FW
Building a portal using the Portal Engine
Index
Portal Engine
Configuring Coplets
Section Home
The URICoplet
The CachingURICoplet
Layout and Skins
Event Handling
Profiles
WSRP Support
Authentication
Form handling
A Basket
Connect to SAP R/3
API (Javadoc)
Tutorials
Index
WebApp
Custom Generator
Tutorial screenshots
RMIServer
FAQ
Index
Install
Configure
CVS/SVN
Configure C2
Databases
XSP
XSLT
Debugging
Generators
Transformers
Serializers
Matchers
Selectors
Actions
Aggregators
How Tos
Index
Samples
Paginator
HTML-PDF
Web Syndication
Flow Debugger
Author How-To
Author FAQ
Author Snippet
Author Docs
Prepare patch
Bugzilla
Performance
Snippets
Index
XSLT Processor Options
Internal Pipeline
Wiki Docs
Status
Changes
To Do
Planning Notes
Overview
Planning Overview
Roadmap
Documentation
Overview
Fix broken links
Other Planning
Release Plan
Cocoon Samples
Proposed TOC
Updating Cocoon
Patch queue
Community
Cocoon Bylaws
Hall of Fame
Contributing
Mail Lists
Mail Archives
Project
Bug Database
Code Repository
Dev Snapshots
Other Releases
Cocoon 1.x
Cocoon 2.0
External
2005 Get Together
The Sitemap
The Sitemap
Introduction
This document describes the Cocoon sitemap concept in full details, why it's
there, what it does, how it works and how you can use it.
Note
See the
User documentation
for details
about configuration of each sitemap component. See the
Example sitemap snippets
. Explore each
sitemap.xmap
in the distribution, to see how the various situations are
handled.
Goals
The goal of the sitemap is to allow non-programmers to create web sites and
web applications built from logic components and XML documents.
It finds inspiration from both Apache's httpd.conf/.htaccess files as well as
from Servlet API 2.2 WAR archives. It uses concepts such as Cascading from W3C
CSS, as well as declarative approaches integrated into the W3C XSLT language. It
also uses some element/attribute equivalence patterns used in W3C RDF.
The following goals were identified as engineering constraints:
minimal verbosity is of maximum importance.
the schema should be sufficiently expressive to allow learning by examples.
sitemap authoring should not require assistive tools, but be sufficiently
future-compatible to allow them.
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
increase.
sitemaps should contain all the information required to Cocoon to generate
all the requests it receives.
sitemaps should contain information for both dynamic operation as well as
offline generation.
uri mapping should be powerful enough to allow every possible mapping need.
basic web-serving functionalities (redirection, error pages, resource
authorisation) should be provided.
sitemaps should not limit Cocoon's intrinsic modular extensibility.
resources must be matched with all possible state variables, not only with
URI (http parameters, environment variables, server parameters, time, etc...).
sitemaps should embed the notion of "semantic resources" to be
future-compatible with semantic crawling and indexing.
sitemaps should be flexible enough to allow a complete web site to be built
with Cocoon.
The Structure
The Sitemap has the following general structure:
The
The default namespaces are used mainly for versioning, instead of using
attributes such as version="1.0" which could create confusion. People are used
to writing URIs with no spelling mistakes, while versioning could be used for
their own sitemap versions and this might break operation.
The versioning schema will be "major.minor" where major will be increased by
one each time a new release breaks backwards compatibility, while minor is
increased each time a change has been made that doesn't create backwards
compatibility problems.
The
Common Attributes of Components
All components have some common attributes. The list below will show and
explain them:
name: Gives the component an identifying name by which it may be referenced
in the pipeline section.
src: Specifies the class implementing this component.
Component Parameters
All components are configured with parameters specified in their child
elements at component instantiation time. The following example shows how to
specify a
parameter for an XSLT
transformation component:
The name and meaning of the parameters are dependent on the component.
Generators
Generator
generates XML content
as SAX events and initializes the pipeline processing.
...
The
default
attribute on
specifies
the type of generator to use if none is specified in a pipeline.
Transformers
Transformer
transforms SAX
events into other SAX events.
The
default
attribute on
specifies the type of transformer to use if none is specified in a pipeline.
Serializers
Serializer
transforms SAX
events in binary or char streams for final client consumption.
The
default
attribute on
specifies
the type of serializer to use if none is specified in a pipeline.
Selectors
Selector
is used to implement
basic conditional logic (
if-then-else
or
switch
) inside the
sitemap. As can be seen in the
Selector
interface, this
functionality decomposes into the ability to evaluate a boolean condition.
...
...
...
The
default
attribute on
specifies
the type of selector to use if none is specified in a pipeline.
Matchers
Matcher
maps a pattern to a
resource.
...
...
The
default
attribute on
specifies the
type of matcher to use if none is specified in a pipeline.
Actions
An
Action
is a sitemap component
that manipulates runtime parameters based on request and application state. An
Action's result is available in the sitemap as map of name/value pairs. Detailed
information on actions may be found in
the Actions
section
The
The
element defines different view of the site.
Views are defined independent of pipelines and might be used with any pipeline
defined in the sitemap. For more on views read
the Views
section
The
The
element is used as a placeholder for
pipelines that are used several times inside the document.
The
The
element is used to arrange actions in
groups (See
the Actions section
for details).
Pipelines
Introduction
Cocoon relies on the pipeline model: an XML document is pushed through a
pipeline, that exists in several transformation steps of your document. Every
pipeline begins with a generator, continues with zero or more transformers, and
ends with a serializer. Beside this normal processing each pipeline may define
its own error handling, too.
Beside using the various components, you can use matchers, and selectors to
choose a specific pipeline processing. Aggregation allows you to build a
hierarchy of pipelines.
Using views allows you to define exit points in a pipeline.
Define a Pipeline
Defining a pipeline is simple. Just write a
map:pipeline
element
inside the
map:pipelines
element.
Fixme
Explain optional attribute
internal-only
Pipeline Elements
Having defined a pipeline you can use following sitemap elements:
Element
Description
map:match
Selects pipeline processing depending on matching
map:select, map:when, map:otherwise
Selects pipeline processing depending on selecting
map:mount
Mounts a sub sitemap
map:redirect-to
Redirects to a another URI
map:call
Goto another pipeline fragment
map:parameter
Defines additional parameters for the sitemap components
map:act
Peform action processing
map:generate
Defines the generation step
map:aggregate, map:part
Defines an alternate generation step by mergine pipelines
map:transform
Defines zero or more transformation steps
map:serialize
Defines the final serialization step
map:handle-errors
Handles processing errors
The usage of these sitemap elements is explained in the following sections in
more detail.
Matching
These powerful sitemap components allow Cocoon to associate a pure "virtual"
URI space to a given set of instructions that describe how to generate,
transform and present the requested resource(s) to the client.
See also
Implementing Matchers And Selectors
Selecting And Testing
Selectors in Apache Cocoon have a role similar to matchers while being more
flexible. Like matchers they are designed to test something against a part of
the environment (the request URI, headers, cookies and so on), but unlike
matchers they can be active decision driving components. A matcher allows only
for simple "yes/no" decisions: the match can be succesful or not, if it is the
pipeline is executed, if not it's simply ignored. Selectors go a step further
allowing for more complex use cases, where there is need for a decision to be
made according to a multiple chance scenario. In short you can think of matchers
as an "if" statement, while selectors have all the power of an "if-else if-else"
or "switch-case" construct. The selector syntax is similar will be familiar to
people using the XSLT
See also
Implementing Matchers And Selectors
Acting
Apache Cocoon has a rich set of tools for publishing web documents, and while
XSP and Generators provide alot of functionality, they still mix content and
logic to a certain degree. The Action was created to fill that gap. Because the
Cocoon Sitemap provides a mechanism to select the pipeline at run time, we
surmised that sometimes we need to adjust the pipeline based on runtime
parameters, or even the contents of the Request parameter. Without the use of
Actions this would make the sitemap almost incomprehensible.
See also
Creating And Using Actions
Generating
A generator is the starting point of an xml pipeline. It generates XML
content as SAX events and initialize the pipeline processing.
See also
Generators in Cocoon.
Aggregating
An aggregator produces XML content. It is composed of one or more parts, each
of which defined by an XML source. During pipeline processing, all parts of an
aggregator are merged. The name of the parent element which contains the merged
XML content from each part is defined by the value of the map:aggregate's
attribute called element.
You can define an aggregator in places where you define a generator. Defining
an aggregator is simple. The example belows defines an aggregate, the merged in
parts will become children of element
the-aggregated-content
Defining an aggregator implicits defining the parts building up the content
of an aggregate.
Define parts inside of an aggregate. You can define as source of a part a
URL. The following list of examples summarizes some useful part sources:
Use
to merge in xml content via http protocol,
received from machine foo.
Use
context://servlet-context-path/foo/bar
to merge in xml content
from the servlet context.
Use
cocoon:/current-sitmap-pipeline/foo/bar
to merge in xml content
from the current sitemap. The appropriate pipeline is selected matching
current-sitemap-pipeline
Use
cocoon://root-sitmap-pipeline/foo/bar
to merge in xml content
from the root sitemap. The appropriate pipeline is selected matching
root-sitemap-pipeline
Use
resource://class-path-context/foo/bar
to merge in xml content
from the classpath.
Use
jar:http://www.foo.com/bar/jar.jar!/foo/bar
to merge in xml
content coming from a jar via http connection.
Use
file:///foo/bar
to merge in xml content from the filesystem.
Use
xmldb:
to
merge in xml content from a XML:DB compliant database.
Depending on your setup you may use
nfs:
jndi:
protocols, too.
Defining a part element of an aggregate is simple. A part element specifies
by its src attribute the source of the xml content.
The following example is taken from the documentation sitemap. The xml
content of pipelines matching
book-*.xml
, and
body-*.xml
is
aggregated having root element site.
...
The aggregated xml content may look like this:
...
Transforming
A transformer is the central point in the pipeline. It transform SAX events
in SAX events.
See also
Transformers in Cocoon.
Serializing
A serializer is the end point of an xml pipeline. It transform SAX events in
binary or char streams for final client consumption.
See also
Serializers in Cocoon.
Handling Errors
Each pipeline may define its error handling. A error handler is specialized
pipeline having a pre-configures generator. Each error handler uses the
generator named
!error-notifier!
. Thus you do not define a generator
inside the error handler. Beside this issue you configure the error handler like
a pipeline. Thus you can choose your transformer, and serializer, and all other
features of pipeline processing.
You may define the error handler as last element of a pipeline. A error
handler may have a type attribute describing which error is handled. By default
an error handler handles status code 500.
The following example defines an error handler, transforming the content of
the error content by the xslt, and i18n transformer, and finally serializing
html.
...
Viewing
Basically, views let you specify exit points of your pipelines that are taken
whenever a particular view is requested. The processing continues with the
definitions in the requested view. The advantage over selectors that could
achieve the same is, that these exit points are not necessarily declared for
each pipeline individually, but once per sitemap.
Redirecting
Redirecting forwards the the request. You may externally send an redirect
response to the client. The behaviour is controlled by using the approriate
attributes of the element
redirect-to
The attribute
uri
defines the target of redirect. The target is sent
as redirect response to the client. The optional attribute
session
specifies, if the redirect should happen inside of a session or not. Setting
session
to
yes
, or
true
will persist a session across
the redirect response. Use enable the session option if you use http session
within your web application.
The following example redirects to a welcome page:
...
Calling resources
Calling resources is dissimilar to redirects as the client does not notice
this.
When calling a resource, arbitrary parameters can be specified. They will be
available to the processing later on, just like the parameters set by e.g.
matchers or actions. Calling a resource always creates a new map of parameters.
Note
The behaviour of resources has slightly changed due to the
introduction of the TreeProcessor in Cocoon. Since 2.1 the sitemap interpreter
strategy allows for the Resources to be templating any composed portion of a
pipeline. (Prior to 2.1 Resources were 'ending' pipelines and as such a call of
resource was said 'not to return')
The following example shows how to define and call sitemap resources:
Mounting sitemaps
Mount points allow sitemaps to be cascaded and site management workload to be
parallelized. This creates a tree of sitemaps with the main sitemap at the root
and possibly several sub-sitemaps as nodes and leaves.
The sub-sitemaps serve two important goals: scalability and simplification of
maintenance. The different sub-sitemaps are independent and don't affect each
other.
The src attribute is where the sub-sitemap is located. If it ends in a slash
"sitemap.xmap" is appended to find the sitemap, otherwise the src value is used.
A check-reload attribute can be used to determine if the modification date of
the sub-sitemap file should be checked. The uri-prefix is the part that should
be removed from the request URI. The engine will correctly check for a trailing
slash (which you may write, of course). If in the example above "faq/cocoon" is
requested, "faq/" is removed from the URI and "cocoon" is passed to the
sub-sitemap which is loaded from "faq/sitemap.xmap".
Sitemap components (generators, transformers, etc.) in a sitemap are
accessible from a sub-sitemap by their names. This is due to the fact that each
sitemap has its own SitemapComponentManager and they are arranged in the same
hierarchical structure as the sitemaps are and thus knows which are their parent
SitemapComponentManager and can ask it for a SitemapComponent it doesn't know
about.
Use Cases
Usually you use the same SitemapComponents over and over again in your
sub-sitemaps. And because you have a contract between the parent and sub
sitemaps (the uri-prefix) you can deliver common SitemapComponents from the
parent sitemap to your sub-sitemaps as well. If you break a sitemap all its
sub-sitemaps are broken as well (because of the hierarchical arrangement).
However you can create independent sub-sitemaps, which meet the following
goals:
Simplify site construction
Reduce risk of "bad' sitemap entries killing whole site
Ease deployment of pre-built applications
Keep sitemap files an understandable and manageable size
Just build a main sitemap with the minimum needs: A matcher and a selector.
These two components allow to select and direct to mount two other sitemaps.
These sub-sitemaps load the components they need (which includes generators and
transformers etc...) and have the map elements for that site/application. The
benefit is that each sitemap is completely independent of each other and any
error in that sitemap does not kill any other sitemap.
Here is an example of a main sitemap. You will notice that it is using a
selector that matches on host name of the request, but any matcher or selector
would work at this point. Both sub-sitemaps are mounted at the root level.
src="org.apache.cocoon.matching.WildcardURIMatcher"/>
src="org.apache.cocoon.selection.HostSelector">
Reloading
The reloading of the sub-sitemaps can be configured by two attributes,
"check-reload" and "reload-method".
The "check-reload" attribute specifies whether the sitemap should be reloaded
(regenerated) if it's source XML (sitemap.xmap) is modified. If "check-reload"
is set to "no", the sitemap is only generated on the first request for this
sitemap. If "check-reload" is set to "yes" (the default), the "reload-method"
attribute determines how the sitemap is regenerated if it had changed.
If "reload-method" is set to "asynchron" (the default), then the next request
for the changed sitemap causes it to be regenerated in the background, and the
request is served with the old one. All subsequent requests are served with the
old sitemap until the regeneration in the background has finished. If the
reload-method is set to "synchron", the sitemap is first regenerated and then
the request is processed.
File: URLs
In your sitemaps you may need to refer to some resource that is outside the
webapp context (e.g. UNIX /foo/bar/this.xsl e.g. Windows C:\foo\bar\this.xsl).
You need to use the file: convention with the following syntax for absolute
filesystem pathnames.
UNIX ...
file:///foo/bar/this.xsl
Windows ...
file:///C:/foo/bar/this.xsl
Everything starting with a URI scheme identifer like "file:" or "http:" is an
absolute URI. An absolute file URL is
file://some.host/some/path/to/file.ext
... the host can be omitted,
defaulting to localhost, so you can write
file:///some/path/to/file.ext
Further information is at RFC2396:
Uniform Resource Identifiers
(URI): Generic Syntax
Protocols
In the sitemap, you can use all protocols nearly everywhere (except for in
map:redirect
).
Inside your components, you can also use these protocols whenever you have a
SourceResolver
handy.
context://
- get a resource using the servlet context
cocoon:/
- get a pipeline from the current sitemap
cocoon://
- get a pipeline using the root sitemap
resource://
- get a resource from the context classloader
Interface specifications
XMLProducer
This interfaces identifies classes that produce XML data, sending SAX events
to the configured
XMLConsumer
It is beyond the scope of this interface to specify a way in which the XML data
production is started.
public interface XMLProducer {
/**
* Set the XMLConsumer that will
* receive XML data.
*/
public void setConsumer(XMLConsumer consumer);
XMLConsumer
This interfaces identifies classes that consume XML data, receiving
notification of SAX events.
This interface unites the idea of SAX
ContentHandler
and
LexicalHandler
public interface XMLConsumer extends ContentHandler,
LexicalHandler {
XMLPipe
This interfaces identifies classes that consume XML data, receiving
notification of SAX events, and also that produce XML data, sending SAX events
to the configured
XMLConsumer
This interface unites the idea of
XMLProducer
and
XMLConsumer
public interface XMLPipe extends XMLConsumer , XMLProducer {
SitemapModelComponent
All sitemap components producing XML must implement this interface:
public interface SitemapModelComponent extends Component {
/**
* Set the SourceResolver, objectModel
* Map, the source and sitemap
* Parameters used to process the request.
*/
void setup(SourceResolver resolver, Map objectModel,
String src, Parameters par)
throws ProcessingException, SAXException, IOException;
SitemapOutputComponent
All sitemap components creating the output must implement this interface:
public interface SitemapOutputComponent extends Component {
/**
* Set the OutputStream where the requested
* resource should be serialized.
*/
void setOutputStream(OutputStream out) throws IOException;
/**
* Get the mime-type of the output of this
* Component.
*/
String getMimeType();
/**
* Test if the component wants to set the content length
*/
boolean shouldSetContentLength();
Generator
Generator
must implement at least the following interface:
public interface Generator extends XMLProducer,
SitemapModelComponent {
String ROLE = "org.apache.cocoon.generation.Generator";
public void generate()
throws IOException, SAXException, ProcessingException;
Transformer
Transformer
must implement at least the following interface:
public interface Transformer
extends XMLPipe, SitemapModelComponent {
String ROLE = "org.apache.cocoon.transformation.Transformer";
Serializer
Serializer
gets the
OutputStream
where the XML should be
serialized with the following interface:
public interface Serializer extends XMLConsumer, SitemapOutputComponent {
String ROLE = "org.apache.cocoon.serialization.Serializer";
Selector
Selector
gets an expression to evaluate and signals the evaluation
with a boolean value.
public interface Selector extends Component {
String ROLE = "org.apache.cocoon.selection.Selector";
/**
* Selectors test pattern against some objects in a Map
* model and signals success with the returned boolean value
* @param expression The expression to test.
* @param objectModel The Map containing object of the
* calling environment which may be used
* to select values to test the expression.
* @param parameters The sitemap parameters, as specified by
* <parameter/> tags.
* @return boolean Signals successfull test.
*/
boolean select (String expression, Map objectModel,
Parameters parameters);
Matcher
Matcher
matches a pattern against any value:
public interface Matcher extends Component {
String ROLE = "org.apache.cocoon.matching.Matcher";
/**
* Matches the pattern against some Request values
* and returns a Map object with replacements
* for wildcards contained in the pattern.
* @param pattern The pattern to match against. Depending on
* the implementation the pattern can contain
* wildcards or regular expressions.
* @param objectModel The Map with object of the
* calling environment which can be used
* to select values this matchers matches against.
* @return Map The returned Map object with
* replacements for wildcards/regular-expressions
* contained in the pattern.
* If the return value is null there was no match.
*/
Map match (String pattern, Map objectModel, Parameters parameters);
Action
An
Action
processes input
objectModel
and returns results
in a
Map
public interface Action extends Component, ThreadSafe {
String ROLE = "org.apache.cocoon.acting.Action";
/**
* Controls the processing against some values of the
* Dictionary objectModel and returns a
* Map object with values used in subsequent
* sitemap substitution patterns.
* NOTE: It is important that Action classes are
* written in a thread safe manner.
* @param resolver The SourceResolver in charge
* @param objectModel The Map with object of the
* calling environment which can be used
* to select values this controller may need
* (ie Request, Response).
* @param source A source String to the Action
* @param parameters The Parameters for this invocation
* @return Map The returned Map object with
* sitemap substitution values which can be used
* in subsequent elements attributes like src=
* using a xpath like expression:
* src="mydir/{myval}/foo"
* If the return value is null the processing
* inside the
* will be skipped.
* @exception Exception Indicates something is totally wrong
*/
Map act(Redirector redirector, SourceResolver resolver,
Map objectModel, String source, Parameters par)
throws Exception;
Additional resources
Learn more about advanced Sitemap features by downloading the free chapter,
User's Look at the Cocoon architecture,
from Langham and Ziegeler's
Cocoon: Building XML Applications
available at the New Riders web site.
Check out a draft XML Schema
grammar
for the Cocoon sitemap
, and some
external documentation
generated
from this Schema. A poster diagram of the sitemap structure is also available.
Errors and Improvements?
If you see any errors or potential improvements in this document
please help us:
View, Edit or comment on
the latest development version (registration required).
Copyright ©
1999-2005
The Apache Software Foundation.
Send feedback about the website to:
dev@cocoon.apache.org