stefano 00/06/15 14:44:40
Modified: xdocs/drafts Tag: xml-cocoon2 sitemap-working-draft.xml Log: many changes: - incorporated Ross' set-parameter proposal - fixed a typo about src:jar - added comments on <semantic-view> - changed the root element to <sitemap> since <cocoon> will likely be somplace else - mix typos Please, go thru the changes and comment them at wish. Thanks. Revision Changes Path No revision No revision 1.1.2.2 +64 -14 xml-cocoon/xdocs/drafts/Attic/sitemap-working-draft.xml Index: sitemap-working-draft.xml =================================================================== RCS file: /home/cvs/xml-cocoon/xdocs/drafts/Attic/sitemap-working-draft.xml,v retrieving revision 1.1.2.1 retrieving revision 1.1.2.2 diff -u -r1.1.2.1 -r1.1.2.2 --- sitemap-working-draft.xml 2000/06/06 23:23:47 1.1.2.1 +++ sitemap-working-draft.xml 2000/06/15 21:44:39 1.1.2.2 @@ -44,7 +44,7 @@ ============================================================================== -This docuemnt contains an example used as a working draft for +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. @@ -127,12 +127,11 @@ --> -<cocoon xmlns="http://xml.apache.org/cocoon/config/2.0"; xmlns:src="http://xml.apache.org/cocoon/loaders";> +<sitemap + xmlns="http://xml.apache.org/cocoon/sitemap/2.0"; + xmlns:src="http://xml.apache.org/cocoon/loaders"; +> - <!-- here should go Cocoon-specific parameters --> - - <sitemap> - <!-- NOTE (SM) Components are included _inside_ the sitemap to allow cascading. This @@ -154,6 +153,12 @@ Component ComponentManager.getComponent(String role) --> + + <!-- NOTE (SM) + Should we allow Avalon blocks to be accessible directly from here? + (this would require Block to implement Component as well) + --> + <component role="pool" src:class="org.apache.cocoon.component.DatabasePool"> <param name="max-connections">10</param> </component> @@ -250,8 +255,6 @@ [XXX] Should we use '$1' for both rules? or keep wildcard positioning like shown below? - [XXX] Should we use a different namespace for the "rule" attribute, like we did for loaders? - --> <!-- @@ -260,7 +263,7 @@ <mount uri="^/xerces-[j|c|p]/(.*)$" src:cvs=":pserver:[EMAIL PROTECTED]:/home/cvs/xerces-$1/xdocs/$2" rule="regexp"/> <mount uri="cocoon/*" src:cvs=":pserver:[EMAIL PROTECTED]:/home/cvs/cocoon/xdocs/*"/> <mount uri="bugs/*" src:jar="./apps/bugs.cocoon#*"/> - <mount uri="faq/*" src:jar="jar:./apps/faq-o-matic.cocoon#*"/> + <mount uri="faq/*" src:jar="./apps/faq-o-matic.cocoon#*"/> <mount uri="dist/*" src:local="./dist/*"/> <!-- @@ -319,11 +322,42 @@ </process> <process uri="complex-semantics/*"> - <semantic-source> + <semantic-view> <generate type="parser" src:local="./complex-semantics/*"/> <filter type="xslt" src:local="./stylesheet/rdf-izer.xsl"/> <filter type="xslt" src:local="./stylesheet/xlink-izer.xsl"/> - </semantic-source> + </semantic-view> + <!-- + 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 + 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... + + [XXX] should we define more exit points that "end" and "semantic"? + + [XXX] the use of such element is not very elegant, any + alternative proposal? + + [XXX] when called internally by the command line wrapper, Cocoon + will know the semantic view was called for, but when accessed + from the normal HTTP channels, how should Cocoon know that? + Should we define our own "semantic" HTTP action? would CC/PP + handle this as well? + --> + <if type="browser accepts text/vnd.wap.wml"> <filter type="xslt" src:local="./stylesheet/rdf2wml.xsl"/> <serialize type="xml"/> @@ -334,6 +368,24 @@ </else> </process> + <process uri="/\([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. + --> + <set-parameter name="year" value="$1"/> + <set-parameter name="month" value="$2"/> + <set-parameter name="day" value="$3"/> + + <generator name="serverpages" src="/dailynews.xsp"> + <filter type="xslt" src:local="./stylesheet/news.xsl"/> + <serializer type="html"/> + </process> + <process uri="*"> <generate type="parser" src:local="*.xml"/> <if test="load greater-then 2.5"> @@ -370,9 +422,7 @@ <filter type="xslt" src:local="./stylesheets/general-browser.xsl"/> <serializer type="html" status-code="401"/> </resource> - - </sitemap> -</cocoon> +</sitemap> <!-- end of file -->
