cocoon-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From stef...@locus.apache.org
Subject cvs commit: xml-cocoon/xdocs/drafts sitemap-working-draft.xmap
Date Fri, 30 Jun 2000 17:21:33 GMT
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 (stefano@apache.org) and Pierpaolo Fumagalli (pier@apache.org)
  +Mazzocchi <stefano@apache.org> and Pierpaolo Fumagalli <pier@apache.org>
   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:anonymous@xml.apache.org://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:anonymous@xml.apache.org://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:anonymous@xml.apache.org://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:anonymous@xml.apache.org://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 -->
  
  
  

Mime
View raw message