stefano 00/06/30 10:21:31
Modified: xdocs/drafts Tag: xml-cocoon2 sitemap-working-draft.xmap
Log:
latest big changes
Revision Changes Path
No revision
No revision
1.1.2.5 +279 -239 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.4
retrieving revision 1.1.2.5
diff -u -r1.1.2.4 -r1.1.2.5
--- sitemap-working-draft.xmap 2000/06/22 13:33:16 1.1.2.4
+++ sitemap-working-draft.xmap 2000/06/30 17:21:31 1.1.2.5
@@ -50,16 +50,11 @@
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])
+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 create a solid foundation
-of sitemap programmability and usability to the Cocoon Publishing
+design patterns and usability guidelines to the Cocoon Publishing
Framework.
-This is one of the few examples where open source is transformed into
-"open development" leading both the implementation and the pure research
-around software development and usability.
-
The goal of the sitemap is to allow non-programmers to create web sites
and web applications built from logic components and XML documents.
@@ -70,35 +65,35 @@
used in W3C RDF.
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, but be
-sufficiently future-compatible to allow them.
-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
-increase.
-5) sitemaps should contain all the information required to Cocoon to
-generate all the requests 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.
-8) basic web-serving functionalities (redirection, error pages,
-resource authorisation) should be provided.
-9) sitemaps should not limit Cocoon's intrinsic modular extensibility.
-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" to be
-future-compatible with sematic crawling and indexing.
-12) sitemaps should be flexible enough to allow a complete web site to
-be built with Cocoon.
-
-======================================================================= -->
-<!--
+ - 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
@@ -110,27 +105,19 @@
is increased each time a change has been made that doesn't create
back incompatible problems.
- -->
-
-<!--
-
- NOTE (SM)
+ The syntax
- the syntax
-
<xxx map:value="yyy">
is completely equivalent to
<xxx>yyy</xxx>
-
- throughout the entire sitemap.. the "value" attribute is a reserved one.
-
- [XXX] (SM) should we use the "map" namespace for this special attribute?
--->
+ throughout the entire sitemap.
-<map:sitemap xmlns:map="http://xml.apache.org/cocoon/sitemap/1.0";>
+============================================================================
-->
+
+<map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0";>
<!-- =========================== Components ================================
-->
@@ -141,35 +128,37 @@
pipeline processing.
-->
<map:generators default="parser">
- <map:generator type="parser"
src="class:///org.apache.cocoon.generator.FileGenerator"/>
- <map:generator type="dir"
src="file:///home/mystuff/java/MyDirGenerator.class"/>
- <map:generator type="xsp"
src="class:///org.apache.cocoon.generators.XSPGenerator">
+ <map:generator type="parser"
src="class:///org.apache.cocoon.generator.FileGenerator" label="content"/>
+ <map:generator type="dir"
src="file:///home/mystuff/java/MyDirGenerator.class" label="content"/>
+ <map:generator type="xsp"
src="class:///org.apache.cocoon.generators.XSPGenerator" label="content">
...
</map:generator>
</map:generators>
<!--
- Filters transform SAX events in SAX events.
+ Transformers transform SAX events in SAX events.
-->
- <map:filters default="xslt">
- <map:filter type="xslt"
src="class:///org.apache.cocoon.filter.XSLTFilter">
- <compile-stylesheets value="true"/>
- </map:filter>
- <map:filter type="xinclude"
src="class:///org.apache.cocoon.filter.XIncludeFilter"/>
- </map:filters>
+ <map:transformers default="xslt">
+ <map:transformer type="xslt"
src="class:///org.apache.cocoon.transformer.XSLTTransformer">
+ <compile-stylesheets map:value="true"/>
+ </map:transformer>
+ <map:transformer type="xinclude"
src="class:///org.apache.cocoon.transformer.XIncludeTransformer"
label="content"/>
+ <map:transformer type="schema"
src="class:///org.apache.cocoon.transformer.SchemaLoader"/>
+ <map:transformer type="rdf"
src="class:///org.apache.cocoon.transformer.RDFizer"/>
+ </map:transformers>
<!--
- Serializers transform SAX events in binary or char streams for
+ Serializers serialize SAX events in binary or char streams for
final client consumption.
-->
<map:serializers default="html">
<map:serializer type="html" mime-type="text/html"
src="class:///org.apache.cocoon.serializer.HTMLSerializer">
- <doctype-public value="-//W3C//DTD HTML 4.0 Transitional//EN"/>
- <doctype-system value="http://www.w3.org/TR/REC-html40/loose.dtd"/>
- <preserve-space value="true"/>
- <encoding value="UTF-8"/>
- <indent value="1"/>
- <line-width value="120"/>
+ <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 map:value="1"/>
+ <line-width map:value="120"/>
</map:serializer>
<map:serializer type="wap" mime-type="text/vnd.wap.wml"
src="class:///org.apache.cocoon.serializer.XMLSerializer">
@@ -179,13 +168,13 @@
</map:serializer>
<map:serializer type="svg2jpg" mime-type="image/jpg"
src="class:///org.apache.cocoon.serializer.SVGSerializer">
- <format value="jpg"/>
+ <format map:value="jpg"/>
<compression-level>80%</compression-level>
</map:serializer>
<map:serializer type="svg2png" mime-type="image/png"
src="class:///org.apache.cocoon.serializer.SVGSerializer">
<format>png</format>
- <color-depth value="24"/>
+ <color-depth map:value="24"/>
</map:serializer>
</map:serializers>
@@ -206,7 +195,7 @@
...
</map:chooser>
- <map:chooser type="browser"
src="class:///org.apache.cocoon.matcher.BrowserChooser">
+ <map:chooser type="browser"
src="class:///org.apache.cocoon.chooser.BrowserChooser">
...
</map:chooser>
</map:choosers>
@@ -229,6 +218,58 @@
</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 =================================
-->
<!--
@@ -247,196 +288,195 @@
<map:resources>
<map:resource name="Access refused">
- <map:generator src="./error-pages/restricted.xml"/>
- <map:filter src="./stylesheets/general-browser.xsl"/>
- <map:serializer status-code="401"/>
+ <map:generate src="./error-pages/restricted.xml"/>
+ <map:transform src="./stylesheets/general-browser.xsl"/>
+ <map:serialize status-code="401"/>
</map:resource>
</map:resources>
-
-<!-- =========================== Sitemap ===================================
-->
- <!--
- Mount points allow sitemaps to be cascaded and site management
- workload to be parallelized.
- -->
- <map:match pattern="cocoon/*">
- <map:mount src="cvs:pserver:[EMAIL
PROTECTED]://home/cvs/cocoon/xdocs/{1}"/>
- </map:match>
-
- <map:match pattern="bugs/*">
- <map:mount src="jar://apps/bugs.cocoon#{1}"/>
- </map:match>
-
- <map:match pattern="dist/*">
- <map:mount src="./dist/{1}"/>
- </map:match>
-
- <map:match pattern="faq/*">
- <map:mount src="jar://apps/faq-o-matic.cocoon#{1}"/>
- </map:match>
-
- <map:match type="uri-regexp" pattern="^/xerces-(j|c|p)/(.*)$">
- <map:mount src="cvs:pserver:[EMAIL
PROTECTED]://home/cvs/xerces-{1}/xdocs/{2}"/>
- </map:match>
-
- <!--
- Matchers declarative dispatch the requests to the pipelines that
- match some of their parameters
- -->
- <map:match pattern="cocoon/dist/*">
- <map:choose type="ip-filter">
- <map:when test="allowsAddress()">
- <!--
- the <redirect> element is used to redirect one requested URI
- to another. This is somewhat equivalent to URI rewriting.
- -->
- <map:redirect to="dist/cocoon/{1}"/>
- </map:when>
- <map:otherwise>
- <map:resource name="Access refused"/>
- </map:otherwise>
- </map:choose>
- </map:match>
+<!-- =========================== Pipelines =================================
-->
- <!--
- 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:filter src="./stylesheet/printer-friendly.xsl"/>
- <map:serialize/>
- </map:match>
-
- <map:match pattern="images/logo">
- <map:choose>
- <map:when test="accepts('image/svg')">
- <!--
- the <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:choose>
- <map:when test="accepts('image/png')">
- <map:serialize type="svg2png"/>
+ <map:pipelines>
+ <map:pipeline>
+
+ <!--
+ Mount points allow sitemaps to be cascaded and site management
+ workload to be parallelized.
+ -->
+ <map:match pattern="cocoon/*">
+ <map:mount src="cvs:pserver:[EMAIL
PROTECTED]://home/cvs/cocoon/xdocs/{1}"/>
+ </map:match>
+
+ <map:match pattern="bugs/*">
+ <map:mount src="jar://apps/bugs.cocoon#{1}"/>
+ </map:match>
+
+ <map:match pattern="dist/*">
+ <map:mount src="./dist/{1}"/>
+ </map:match>
+
+ <map:match pattern="faq/*">
+ <map:mount src="jar://apps/faq-o-matic.cocoon#{1}"/>
+ </map:match>
+
+ <map:match type="uri-regexp" pattern="^/xerces-(j|c|p)/(.*)$">
+ <map:mount src="cvs:pserver:[EMAIL
PROTECTED]://home/cvs/xerces-{1}/xdocs/{2}"/>
+ </map:match>
+
+ <map:handle-errors>
+ <map:serialize type="xml"/>
+ </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:choose 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:serialize type="svg2jpg"/>
+ <map:redirect-to resource="Access refused"/>
</map:otherwise>
</map:choose>
- </map:otherwise>
- </map:choose>
- </map:match>
-
- <map:match pattern="restricted/*">
- <map:choose type="user">
- <map:when test="is('administrator')">
- <map:generate src="./restricted/{1}"/>
- <map:filter src="./stylesheets/restricted.xsl"/>
+ </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:when>
- <map:otherwise>
- <map:resource name="Access refused"/>
- </map:otherwise>
- </map:choose>
- </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 src="file:///home/www/mozilla-{1}-{2}/{../1}"/>
- </map:match>
- </map:match>
-
- <map:match pattern="complex-semantics/*">
-
- <!--
- The semantic view should contain all the information that semantic
- crawlers need to fully understand this resource. It normally means
- that RDF, XLink and PI are contained in this view of the resource
- and Cocoon will be able to interrupt the pipeline at this point
- if the client is requesting this.
-
- This will be used for offline crawlers, metadata indexers and
- XML-capable browsers.
- -->
-
- <!-- NOTE (SM)
-
- The semantic-view element might become too specific if the new
- CC/PP (http://www.w3.org/TR/CCPP-ra/) user-agent capabilities
- architecture proposal is implemented. If this happens, the need for
- multiple pipeline exit points depending on the requestor capabilities
- will emerge. But this is clearly _way_ too early to expect, anyway...
-
- -->
+ </map:match>
- <map:view type="semantic">
- <map:generate src="./complex-semantics/{1}"/>
- <map:filter src="./stylesheet/rdf-izer.xsl"/>
- <map:filter src="./stylesheet/xlink-izer.xsl"/>
- </map:view>
+ <map:match pattern="images/logo">
+ <map:choose>
+ <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" mime-type="image/svg"/>
+ </map:when>
+ <map:otherwise>
+ <map:generate src="./images/logo.svg"/>
+ <map:choose>
+ <map:when test="accepts('image/png')">
+ <map:serialize type="svg2png"/>
+ </map:when>
+ <map:otherwise>
+ <map:serialize type="svg2jpg"/>
+ </map:otherwise>
+ </map:choose>
+ </map:otherwise>
+ </map:choose>
+ </map:match>
+ <map:match pattern="restricted/*">
+ <map:choose 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:choose>
+ </map:match>
- <map:choose>
- <map:when test="accepts('text/vnd.wap.wml')">
- <map:filter src="./stylesheet/rdf2wml.xsl"/>
- <map:serialize type="wap"/>
- </map:when>
- <map:otherwise>
- <map:filter src="./stylesheet/rdf2html.xsl"/>
+ <!--
+ 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:otherwise>
- </map:choose>
- </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:generator name="serverpages" src="./dailynews.xsp"/>
- <map:filter src="./stylesheet/{1}/news.xsl"/>
- <map:serializer/>
- </map:match>
-
- <map:match pattern="*">
- <map:generate src="{1}.xml"/>
- <map:choose type="load">
- <map:when test="greaterThen('2.5')">
- <map:filter src="./stylesheet/low-graphics.xsl"/>
- </map:when>
- <map:otherwise>
+ </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 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 name="serverpages" src="./dailynews.xsp"/>
+ <map:transform src="./stylesheet/{1}/news.xsl"/>
+ <map:serialize/>
+ </map:match>
+
+ <map:match pattern="*">
+ <map:generate src="{1}.xml"/>
+ <map:choose type="load">
+ <map:when test="greaterThen('2.5')">
+ <map:transform src="./stylesheet/low-graphics.xsl"/>
+ </map:when>
+ <map:otherwise>
+ <map:choose>
+ <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:choose>
+ </map:otherwise>
+ </map:choose>
+ <map:serialize/>
+ </map:match>
+
+ <map:handle-errors>
<map:choose>
- <map:when test="is('Mozilla5')">
- <map:filter src="./stylesheet/xul-enabled.xsl"/>
+ <map:when test="accepts('text/vnd.wap.wml')">
+ <map:transform src="./styles/Pipeline2WML.xsl"/>
+ <map:serialize type="wap"/>
</map:when>
<map:otherwise>
- <map:filter src="./stylesheet/general-browser.xsl"/>
+ <map:transform src="./styles/Pipeline2HTML.xsl"/>
+ <map:serialize/>
</map:otherwise>
</map:choose>
- </map:otherwise>
- </map:choose>
- <map:serializer/>
- </map:match>
-
+ </map:handle-errors>
+
+ </map:pipeline>
+ </map:pipelines>
+
</map:sitemap>
<!-- end of file -->
