stefano 00/09/27 15:55:26
Modified: xdocs/drafts Tag: xml-cocoon2 sitemap-working-draft.xmap Log: changed "generate-from" to "from-label" and updated semantics Revision Changes Path No revision No revision 1.1.2.15 +452 -457 xml-cocoon/xdocs/drafts/Attic/sitemap-working-draft.xmap Index: sitemap-working-draft.xmap =================================================================== RCS file: /home/cvs/xml-cocoon/xdocs/drafts/Attic/sitemap-working-draft.xmap,v retrieving revision 1.1.2.14 retrieving revision 1.1.2.15 diff -u -r1.1.2.14 -r1.1.2.15 --- sitemap-working-draft.xmap 2000/08/03 20:09:32 1.1.2.14 +++ sitemap-working-draft.xmap 2000/09/27 22:55:26 1.1.2.15 @@ -1,154 +1,154 @@ -<?xml version="1.0"?> - -<!-- =============== Cocoon Sitemap Working Draft ============================ - - Copyright (C) 2000 The Apache Software Foundation. All rights reserved. - - Redistribution of this document is permitted provided that the following - conditions are met: - - 1. Redistributions must retain the above copyright notice, - this list of conditions and the following disclaimer. - - 2. This document is referred to and considered only as "working draft". - - 3. Any software implementation inspired by this document must indicate - in its documentation: - - "inspired by research and development on behalf of the - Apache Software Foundation" - - 4. The names "Cocoon" and "Apache Software Foundation" must not be used to - endorse or promote products inspired from this document without prior - written permission. For written permission, please contact - [EMAIL PROTECTED] - - 5. Products derived from this document may not be called "Cocoon", nor may - "Cocoon" nor "Apache" appear in their name, without prior written - permission of the Apache Software Foundation. - - THIS DOCUMENT IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, - INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND - FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE - APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, - INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLU- - DING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS - OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON - ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF - THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - - This document consists of voluntary contributions made by many individuals - on behalf of the Apache Software Foundation. For more information on the - Apache Software Foundation, please see <http://www.apache.org/>. - -============================================================================== - -This document contains an example used as a working draft for -Cocoon architects to test and understand the issues associated with -sitemaps and XML publishing in general. It must be considered as a working -draft and may be updated at any time. - -This document is based on ideas and design patterns inspired by Stefano -Mazzocchi <[EMAIL PROTECTED]> and Pierpaolo Fumagalli <[EMAIL PROTECTED]> -but grew as a collaborative effort to provide a solid foundation of -design patterns and usability guidelines to the Cocoon Publishing -Framework. - -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 static 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, enviornment variables, server - parameters, time, etc...). - - sitemaps should embed the notion of "semantic resources" to be - future-compatible with sematic crawling and indexing. - - sitemaps should be flexible enough to allow a complete web site to - be built with Cocoon. - - sitemaps should include the notion of "multi-dimensional resource views" - even if HTTP doesn't provide them explicitly. - - sitemaps should include the ability to provide resource creation tracing - and error handling. - - 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 back compatibility, while minor - is increased each time a change has been made that doesn't create - back incompatible problems. - - The syntax - - <xxx map:value="yyy"> - - is completely equivalent to - - <xxx>yyy</xxx> - - throughout the entire sitemap. - -============================================================================ --> - -<map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0";> - xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"; - xsi:schemaLocation="sitemap-working-draft.xsd"> -<!-- xsi:schemaLocation="http://apache.org/cocoon/sitemap/1.0/schema";> --> - -<!-- =========================== Components ================================ --> - - <map:components> - - <!-- - Generators generate XML content as SAX events and initialize the - pipeline processing. - --> - <map:generators default="parser"> - <map:generator name="parser" src="class:///org.apache.cocoon.generation.FileGenerator" label="content"/> - <map:generator name="dir" src="file:///home/mystuff/java/MyDirGenerator.class" label="content"/> +<?xml version="1.0"?> + +<!-- =============== Cocoon Sitemap Working Draft ============================ + + Copyright (C) 2000 The Apache Software Foundation. All rights reserved. + + Redistribution of this document is permitted provided that the following + conditions are met: + + 1. Redistributions must retain the above copyright notice, + this list of conditions and the following disclaimer. + + 2. This document is referred to and considered only as "working draft". + + 3. Any software implementation inspired by this document must indicate + in its documentation: + + "inspired by research and development on behalf of the + Apache Software Foundation" + + 4. The names "Cocoon" and "Apache Software Foundation" must not be used to + endorse or promote products inspired from this document without prior + written permission. For written permission, please contact + [EMAIL PROTECTED] + + 5. Products derived from this document may not be called "Cocoon", nor may + "Cocoon" nor "Apache" appear in their name, without prior written + permission of the Apache Software Foundation. + + THIS DOCUMENT IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, + INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND + FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE + APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, + INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLU- + DING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS + OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON + ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + + This document consists of voluntary contributions made by many individuals + on behalf of the Apache Software Foundation. For more information on the + Apache Software Foundation, please see <http://www.apache.org/>. + +============================================================================== + +This document contains an example used as a working draft for +Cocoon architects to test and understand the issues associated with +sitemaps and XML publishing in general. It must be considered as a working +draft and may be updated at any time. + +This document is based on ideas and design patterns inspired by Stefano +Mazzocchi <[EMAIL PROTECTED]> and Pierpaolo Fumagalli <[EMAIL PROTECTED]> +but grew as a collaborative effort to provide a solid foundation of +design patterns and usability guidelines to the Cocoon Publishing +Framework. + +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 static 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, enviornment variables, server + parameters, time, etc...). + - sitemaps should embed the notion of "semantic resources" to be + future-compatible with sematic crawling and indexing. + - sitemaps should be flexible enough to allow a complete web site to + be built with Cocoon. + - sitemaps should include the notion of "multi-dimensional resource views" + even if HTTP doesn't provide them explicitly. + - sitemaps should include the ability to provide resource creation tracing + and error handling. + + 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 back compatibility, while minor + is increased each time a change has been made that doesn't create + back incompatible problems. + + The syntax + + <xxx map:value="yyy"> + + is completely equivalent to + + <xxx>yyy</xxx> + + throughout the entire sitemap. + +============================================================================ --> + +<map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0";> + xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"; + xsi:schemaLocation="sitemap-working-draft.xsd"> +<!-- xsi:schemaLocation="http://apache.org/cocoon/sitemap/1.0/schema";> --> + +<!-- =========================== Components ================================ --> + + <map:components> + + <!-- + Generators generate XML content as SAX events and initialize the + pipeline processing. + --> + <map:generators default="parser"> + <map:generator name="parser" src="class:///org.apache.cocoon.generation.FileGenerator" label="content"/> + <map:generator name="dir" src="file:///home/mystuff/java/MyDirGenerator.class" label="content"/> <map:generator name="serverpages" src="class:///org.apache.cocoon.generation.XSPGenerator" label="content"> - ... - </map:generator> - </map:generators> - - <!-- - Transformers transform SAX events in SAX events. - --> - <map:transformers default="xslt"> - <map:transformer name="xslt" src="class:///org.apache.cocoon.transformation.XSLTTransformer"> - <compile-stylesheets map:value="true"/> - </map:transformer> - <map:transformer name="xinclude" src="class:///org.apache.cocoon.transformation.XIncludeTransformer" label="content"/> - <map:transformer name="schema" src="class:///org.apache.cocoon.transformation.SchemaLoader"/> - <map:transformer name="rdf" src="class:///org.apache.cocoon.transformation.RDFizer"/> - </map:transformers> + ... + </map:generator> + </map:generators> + + <!-- + Transformers transform SAX events in SAX events. + --> + <map:transformers default="xslt"> + <map:transformer name="xslt" src="class:///org.apache.cocoon.transformation.XSLTTransformer"> + <compile-stylesheets map:value="true"/> + </map:transformer> + <map:transformer name="xinclude" src="class:///org.apache.cocoon.transformation.XIncludeTransformer" label="content"/> + <map:transformer name="schema" src="class:///org.apache.cocoon.transformation.SchemaLoader"/> + <map:transformer name="rdf" src="class:///org.apache.cocoon.transformation.RDFizer"/> + </map:transformers> <!-- Readers generate and serialize directly from a resource in binary or char streams for @@ -162,180 +162,175 @@ Serializers serialize SAX events in binary or char streams for final client consumption. --> - <map:serializers default="html"> - <map:serializer name="html" mime-type="text/html" src="class:///org.apache.cocoon.serialization.HTMLSerializer"> - <doctype-public map:value="-//W3C//DTD HTML 4.0 Transitional//EN"/> - <doctype-system map:value="http://www.w3.org/TR/REC-html40/loose.dtd"/> - <preserve-space map:value="true"/> - <encoding map:value="UTF-8"/> - <indent tab="8">1</indent> - <colors> - <foreground map:value="white"/> - <borders> - <left map:value="blue"/> - <right>red</right> - </borders> - <text>black</text> + <map:serializers default="html"> + <map:serializer name="html" mime-type="text/html" src="class:///org.apache.cocoon.serialization.HTMLSerializer"> + <doctype-public map:value="-//W3C//DTD HTML 4.0 Transitional//EN"/> + <doctype-system map:value="http://www.w3.org/TR/REC-html40/loose.dtd"/> + <preserve-space map:value="true"/> + <encoding map:value="UTF-8"/> + <indent tab="8">1</indent> + <colors> + <foreground map:value="white"/> + <borders> + <left map:value="blue"/> + <right>red</right> + </borders> + <text>black</text> <lines> - <left map:value="cyan"/> - <right>orange</right> - </lines> - <background>green</background> - </colors> - <map:param name="foo" value="bar"/> - <map:param name="baz">foobar</map:param> - <line-width map:value="120"/> - </map:serializer> - - <map:serializer name="wap" mime-type="text/vnd.wap.wml" src="class:///org.apache.cocoon.serialization.XMLSerializer"> - <doctype-public>-//WAPFORUM//DTD WML 1.1//EN</doctype-public> - <doctype-system>http://www.wapforum.org/DTD/wml_1.1.xml</doctype-system> - <encoding>UTF-8</encoding> - </map:serializer> - - <map:serializer name="svg2jpg" mime-type="image/jpg" src="class:///org.apache.cocoon.serialization.SVGSerializer"> - <format map:value="jpg"/> - <compression-level>80%</compression-level> - </map:serializer> - - <map:serializer name="svg2png" mime-type="image/png" src="class:///org.apache.cocoon.serialization.SVGSerializer"> - <format>png</format> - <color-depth map:value="24"/> - </map:serializer> - </map:serializers> - - <!-- - Selectors are classes that contain programming logic that perform - boolean evaluation based on enviornment state during the call (state - includes request parameters, machine state as well as any other - accessible information) - - Selectors can only respond with true/false when called. - --> - <map:selectors default="browser"> - <map:selector name="load" src="class:///org.apache.cocoon.selection.MachineLoadSelector"> - ... - </map:selector> - + <left map:value="cyan"/> + <right>orange</right> + </lines> + <background>green</background> + </colors> + <map:param name="foo" value="bar"/> + <map:param name="baz">foobar</map:param> + <line-width map:value="120"/> + </map:serializer> + + <map:serializer name="wap" mime-type="text/vnd.wap.wml" src="class:///org.apache.cocoon.serialization.XMLSerializer"> + <doctype-public>-//WAPFORUM//DTD WML 1.1//EN</doctype-public> + <doctype-system>http://www.wapforum.org/DTD/wml_1.1.xml</doctype-system> + <encoding>UTF-8</encoding> + </map:serializer> + + <map:serializer name="svg2jpg" mime-type="image/jpg" src="class:///org.apache.cocoon.serialization.SVGSerializer"> + <format map:value="jpg"/> + <compression-level>80%</compression-level> + </map:serializer> + + <map:serializer name="svg2png" mime-type="image/png" src="class:///org.apache.cocoon.serialization.SVGSerializer"> + <format>png</format> + <color-depth map:value="24"/> + </map:serializer> + </map:serializers> + + <!-- + Selectors are classes that contain programming logic that perform + boolean evaluation based on enviornment state during the call (state + includes request parameters, machine state as well as any other + accessible information) + + Selectors can only respond with true/false when called. + --> + <map:selectors default="browser"> + <map:selector name="load" src="class:///org.apache.cocoon.selection.MachineLoadSelector"> + ... + </map:selector> + <map:selector name="user" src="class:///org.apache.cocoon.selection.AuthenticationSelector"> ... </map:selector> <map:selector name="ip-filter" src="class:///org.apache.cocoon.selection.IPFilterSelector"> ... + </map:selector> + + <map:selector name="browser" factory="org.apache.cocoon.selection.BrowserSelectorFactory"> + ... </map:selector> - - <map:selector name="browser" factory="org.apache.cocoon.selection.BrowserSelectorFactory"> - ... - </map:selector> - </map:selectors> - - <!-- - Matchers are classes that are able to test if the request parameters - match the given pattern and, if this is the case, they are able to - return a collection of tokens that resulted from the matching or any - depending on the matcher own logic (this is up to the matcher implementation). - --> - <map:matchers default="uri-wildcard"> - <map:matcher name="uri-wildcard" src="org.apache.cocoon.matching.WildcardURIMatcher"> + </map:selectors> + + <!-- + Matchers are classes that are able to test if the request parameters + match the given pattern and, if this is the case, they are able to + return a collection of tokens that resulted from the matching or any + depending on the matcher own logic (this is up to the matcher implementation). + --> + <map:matchers default="uri-wildcard"> + <map:matcher name="uri-wildcard" src="org.apache.cocoon.matching.WildcardURIMatcher"> + ... + </map:matcher> + + <map:matcher name="uri-regexp" factory="org.apache.cocoon.matching.RegexpURIMatcherFactory"> ... - </map:matcher> - - <map:matcher name="uri-regexp" factory="org.apache.cocoon.matching.RegexpURIMatcherFactory"> - ... - </map:matcher> - - <map:matcher name="browser" src="org.apache.cocoon.matching.BrowserMatcher"> + </map:matcher> + + <map:matcher name="browser" src="org.apache.cocoon.matching.BrowserMatcher"> <foo value="bar">baz</foo> <lines> <left>red</left> <right>white</right> </lines> - </map:matcher> - </map:matchers> - - </map:components> - -<!-- =========================== Views =================================== --> - - <!-- - the <view> element introduces the notion of multi-dimensional resource - views which are an extension to the HTTP paradigm of web resources. Views - do not increase sitemap functionality, but allow substantial verbosity - reduction and should help users in the creation of complex sitemaps that - are able to produce different views of the resource they handle for each - "aspect" requested. - - Views can be pictured as generator-less pipelines which use, as a generator, - the result of another pipeline from the "label" they indicate. - - Labels can be seen as non-standard exit points from the normal pipelines. - - Both generators and transformers are allowed to attach a default label to - them. If no <label> element is explicitly indicated, the sitemap handler - will scan for default labels attached to the components, starting from the - serializer and going backward, until it finds a component to start. - If none is found, the generator is assumed to be the view generator. - - --> - <map:views> - - <map:view name="content" generate-from="content"> - <map:serialize type="xml"/> - </map:view> - - <map:view name="schema" generate-from="content"> - <map:transform type="schema"/> - <map:serialize type="xml"/> - </map:view> - - <map:view name="semantics" generate-from="content"> - <map:transform type="rdf"/> - <map:serialize type="xml"/> - </map:view> - - <!-- - In this case, this view can be generated from both "links" and "content" - labels, in this order. This means that if the "hyperlinks" view of a resource - is requested, the sitemap will redirect the events from the matching - pipeline to this view when the links label is reached... or, if no - links label is found, from the content label. - --> - <map:view name="hyperlinks" generate-from="links,content"> - <map:transform src="./stylesheets/xlink-filter.xsl"/> - <map:serialize type="xml"/> - </map:view> - - </map:views> - -<!-- =========================== Resources ================================= --> - - <!-- - the <resource> element is used as a placeholder for pipelines - that are used several times inside the document. This element - is redundant and its functionality is not directly related - to the sitemap, but could be cloned by the use of internal - XInclude, for example - - <xinclude:include href="#xpointer([EMAIL PROTECTED]'Access refused'])"/> - - but given the usability constraints and very specific operation - it is much easier to include such an element instead of forcing - the use of xinclude/xpointer. - --> - <map:resources> - - <map:resource name="Access refused"> - <map:generate src="./error-pages/restricted.xml"/> - <map:transform src="./stylesheets/general-browser.xsl"/> - <map:serialize status-code="401"/> - </map:resource> - - </map:resources> + </map:matcher> + </map:matchers> + + </map:components> + +<!-- =========================== Views =================================== --> + + <!-- + the <view> element introduces the notion of multi-dimensional resource + views which are an extension to the HTTP paradigm of web resources. Views + do not increase sitemap functionality, but allow substantial verbosity + reduction and should help users in the creation of complex sitemaps that + are able to produce different views of the resource they handle for each + "aspect" requested. + + Views can be pictured as generator-less pipelines which use, as a generator, + the result of another pipeline from the "label" they indicate or from the + position (first/last) in the pipeline. + + Labels can be seen as non-standard exit points from the normal pipelines + and "first" identifies the position right after the generator while "last + indentifies the position right before the serializer. + + Both generators and transformers are allowed to attach a default label to + them. If no <label> element is explicitly indicated, the sitemap handler + will scan for default labels attached to the components, starting from the + serializer and going backward, until it finds a component to start. + If none is found, the generator is assumed to be the view generator. + --> + <map:views> + <map:view name="content" from-position="first"> + <map:serialize type="xml"/> + </map:view> + + <map:view name="schema" from-label="content"> + <map:transform type="schema"/> + <map:serialize type="xml"/> + </map:view> + + <map:view name="semantics" from-label="content"> + <map:transform type="rdf"/> + <map:serialize type="xml"/> + </map:view> + + <map:view name="hyperlinks" from-position="last"> + <map:transform src="./stylesheets/xlink-filter.xsl"/> + <map:serialize type="xml"/> + </map:view> + + </map:views> + +<!-- =========================== Resources ================================= --> + + <!-- + the <resource> element is used as a placeholder for pipelines + that are used several times inside the document. This element + is redundant and its functionality is not directly related + to the sitemap, but could be cloned by the use of internal + XInclude, for example + + <xinclude:include href="#xpointer([EMAIL PROTECTED]'Access refused'])"/> + + but given the usability constraints and very specific operation + it is much easier to include such an element instead of forcing + the use of xinclude/xpointer. + --> + <map:resources> + + <map:resource name="Access refused"> + <map:generate src="./error-pages/restricted.xml"/> + <map:transform src="./stylesheets/general-browser.xsl"/> + <map:serialize status-code="401"/> + </map:resource> + + </map:resources> + <!-- =========================== Pipelines ================================= --> - <map:pipelines> + <map:pipelines> <map:pipeline> <!-- @@ -371,155 +366,155 @@ </map:handle-errors> </map:pipeline> - - <map:pipeline> - - <!-- - Matchers declarative dispatch the requests to the pipelines that - match some of their parameters - --> - <map:match pattern="cocoon/dist/*"> - <map:select type="ip-filter"> - <map:when test="allowsAddress()"> - <!-- - the <redirect-to> element is used to redirect one requested URI - to another. This is somewhat equivalent to URI rewriting. - --> - <map:redirect-to uri="dist/cocoon/{1}"/> - </map:when> - <map:otherwise> - <map:redirect-to resource="Access refused"/> - </map:otherwise> - </map:select> - </map:match> - - <!-- - When no "type" attribute is present, the sitemap intepreter will use the - default one, this allows a very compact and user friendly syntax as the - one below - --> - <map:match pattern="printer-friendly/*"> - <map:generate src="{1}.xml"/> - <map:transform src="./stylesheet/printer-friendly.xsl"/> - <map:serialize/> - </map:match> - - <map:match pattern="images/logo"> - <map:select> - <map:when test="accepts('image/svg')"> - <!-- - the <map:read> element is used to read the src directly without - applying any processing. This is mostly useful when clients - are capable of handling XML content directly. - --> - <map:read src="./images/logo.svg"/> - </map:when> - <map:otherwise> - <map:generate src="./images/logo.svg"/> - <map:select> - <map:when test="accepts('image/png')"> - <map:serialize type="svg2png"/> - </map:when> - <map:otherwise> - <map:serialize type="svg2jpg"/> - </map:otherwise> - </map:select> - </map:otherwise> - </map:select> - </map:match> - - <map:match pattern="restricted/*"> - <map:select type="user"> - <map:when test="is('administrator')"> - <map:generate src="./restricted/{1}"/> - <map:transform src="./stylesheets/restricted.xsl"/> - <map:serialize/> - </map:when> - <map:otherwise> - <map:redirect-to resource="Access refused"/> - </map:otherwise> - </map:select> - </map:match> - - <!-- - Example to show the notion of pipeline labels for view generation. - --> - <map:match pattern="labelled/*"> - <map:label name="links"> - <map:label name="content"> - <map:generate src="./slides/{1}"/> - </map:label> - <map:transform src="./filters/add-navigation-links.xsl"/> - </map:label> - <map:transform src="./stylesheet/slides2html.xsl"/> - <map:serialize/> - </map:match> - - <!-- - Complex example to show how some xpath-like syntax is used to get access - to the pattern tokens generated by the matchers. - --> - <map:match pattern="nested-matchers/*"> - <map:match type="browser" pattern="name('Mozilla ?\\?*')"> + + <map:pipeline> + + <!-- + Matchers declarative dispatch the requests to the pipelines that + match some of their parameters + --> + <map:match pattern="cocoon/dist/*"> + <map:select type="ip-filter"> + <map:when test="allowsAddress()"> + <!-- + the <redirect-to> element is used to redirect one requested URI + to another. This is somewhat equivalent to URI rewriting. + --> + <map:redirect-to uri="dist/cocoon/{1}"/> + </map:when> + <map:otherwise> + <map:redirect-to resource="Access refused"/> + </map:otherwise> + </map:select> + </map:match> + + <!-- + When no "type" attribute is present, the sitemap intepreter will use the + default one, this allows a very compact and user friendly syntax as the + one below + --> + <map:match pattern="printer-friendly/*"> + <map:generate src="{1}.xml"/> + <map:transform src="./stylesheet/printer-friendly.xsl"/> + <map:serialize/> + </map:match> + + <map:match pattern="images/logo"> + <map:select> + <map:when test="accepts('image/svg')"> + <!-- + the <map:read> element is used to read the src directly without + applying any processing. This is mostly useful when clients + are capable of handling XML content directly. + --> + <map:read src="./images/logo.svg"/> + </map:when> + <map:otherwise> + <map:generate src="./images/logo.svg"/> + <map:select> + <map:when test="accepts('image/png')"> + <map:serialize type="svg2png"/> + </map:when> + <map:otherwise> + <map:serialize type="svg2jpg"/> + </map:otherwise> + </map:select> + </map:otherwise> + </map:select> + </map:match> + + <map:match pattern="restricted/*"> + <map:select type="user"> + <map:when test="is('administrator')"> + <map:generate src="./restricted/{1}"/> + <map:transform src="./stylesheets/restricted.xsl"/> + <map:serialize/> + </map:when> + <map:otherwise> + <map:redirect-to resource="Access refused"/> + </map:otherwise> + </map:select> + </map:match> + + <!-- + Example to show the notion of pipeline labels for view generation. + --> + <map:match pattern="labelled/*"> + <map:label name="links"> + <map:label name="content"> + <map:generate src="./slides/{1}"/> + </map:label> + <map:transform src="./filters/add-navigation-links.xsl"/> + </map:label> + <map:transform src="./stylesheet/slides2html.xsl"/> + <map:serialize/> + </map:match> + + <!-- + Complex example to show how some xpath-like syntax is used to get access + to the pattern tokens generated by the matchers. + --> + <map:match pattern="nested-matchers/*"> + <map:match type="browser" pattern="name('Mozilla ?\\?*')"> <map:mount uri-prefix="nested-matchers/{1}" - src="file:///home/www/mozilla-{1}-{2}/{../1}"/> - </map:match> - </map:match> - - <map:match type="uri-regexp" pattern="([0-9]{4})/([0-9]{2})/([0-9]{2})/"> - <!-- - Here we implement the ability to indicate semantic information - on the processed URI. This is mostly used to avoid to encode - URI specific information in the XSP since the sitemap maintainer - is the only one responsible to manage the URI space. This removes - a URI contract between the XSP writer and the URI space manager, - moving it to parameter names which normally change less frequently. - --> - <map:param name="year" value="{1}"/> - <map:param name="month" value="{2}"/> - <map:param name="day" value="{3}"/> - - <map:generate type="serverpages" src="./dailynews.xsp"/> - <map:transform src="./stylesheet/{1}/news.xsl"/> - <map:serialize/> - </map:match> - - <map:match pattern="*"> - <map:generate src="{1}.xml"/> - <map:select type="load"> - <map:when test="greaterThen('2.5')"> - <map:transform src="./stylesheet/low-graphics.xsl"/> - </map:when> - <map:otherwise> - <map:select> - <map:when test="is('Mozilla5')"> - <map:transform src="./stylesheet/xul-enabled.xsl"/> - </map:when> - <map:otherwise> - <map:transform src="./stylesheet/general-browser.xsl"/> - </map:otherwise> - </map:select> - </map:otherwise> - </map:select> - <map:serialize/> - </map:match> - - <map:handle-errors> - <map:select> - <map:when test="accepts('text/vnd.wap.wml')"> - <map:transform src="./styles/Pipeline2WML.xsl"/> - <map:serialize type="wap"/> - </map:when> - <map:otherwise> - <map:transform src="./styles/Pipeline2HTML.xsl"/> - <map:serialize/> - </map:otherwise> - </map:select> - </map:handle-errors> - - </map:pipeline> - </map:pipelines> + src="file:///home/www/mozilla-{1}-{2}/{../1}"/> + </map:match> + </map:match> + + <map:match type="uri-regexp" pattern="([0-9]{4})/([0-9]{2})/([0-9]{2})/"> + <!-- + Here we implement the ability to indicate semantic information + on the processed URI. This is mostly used to avoid to encode + URI specific information in the XSP since the sitemap maintainer + is the only one responsible to manage the URI space. This removes + a URI contract between the XSP writer and the URI space manager, + moving it to parameter names which normally change less frequently. + --> + <map:param name="year" value="{1}"/> + <map:param name="month" value="{2}"/> + <map:param name="day" value="{3}"/> -</map:sitemap> - -<!-- end of file --> + <map:generate type="serverpages" src="./dailynews.xsp"/> + <map:transform src="./stylesheet/{1}/news.xsl"/> + <map:serialize/> + </map:match> + + <map:match pattern="*"> + <map:generate src="{1}.xml"/> + <map:select type="load"> + <map:when test="greaterThen('2.5')"> + <map:transform src="./stylesheet/low-graphics.xsl"/> + </map:when> + <map:otherwise> + <map:select> + <map:when test="is('Mozilla5')"> + <map:transform src="./stylesheet/xul-enabled.xsl"/> + </map:when> + <map:otherwise> + <map:transform src="./stylesheet/general-browser.xsl"/> + </map:otherwise> + </map:select> + </map:otherwise> + </map:select> + <map:serialize/> + </map:match> + + <map:handle-errors> + <map:select> + <map:when test="accepts('text/vnd.wap.wml')"> + <map:transform src="./styles/Pipeline2WML.xsl"/> + <map:serialize type="wap"/> + </map:when> + <map:otherwise> + <map:transform src="./styles/Pipeline2HTML.xsl"/> + <map:serialize/> + </map:otherwise> + </map:select> + </map:handle-errors> + + </map:pipeline> + </map:pipelines> + +</map:sitemap> + +<!-- end of file -->
