cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <vadim.gritse...@verizon.net>
Subject Re: Examples of invalid pipelines in lint sitemap
Date Fri, 08 Nov 2002 20:05:05 GMT
Colin,

Please take a look at validation rules built into sitemap.xsl 
(cocoon_2_0_3_branch), I hope xsl code in there will clear up things for 
you.


Regards,
Vadim



Colin Paul Adams wrote:

>I am currently adding schematron rules to the RELAX NG schema for
>sitemaps, so as to improve the validating power.
>My first objective is to reject all the examples of invalid pipelines
>within the lint sitemap. I am making progress, but some things are not
>clear to me.
>
>The first example is:
>
>    <!-- Pipeline with no map:generate|read|mount|redirect-to|call is illegal 
>    <map:pipeline>
>      <map:transform src="../../stylesheets/simple-xml2html.xsl"/>
>      <map:serialize/>
>    </map:pipeline>
>    -->
>
>However, upon testing it became clear that this is no longer the
>case. The following assertion however, is sufficient fail the above
>example, whilst not failing any other existing sitemap. I would
>appreciate comments on how accurate or otherwise it is:
>
>	<sch:rule context="xmap:pipeline">
>	  <sch:assert test="(@src and @name) or descendant::*[self::xmap:generate or self::xmap:read
or self::xmap:mount or self::xmap:redirect-to or self::xmap:call]">
>	    Pipeline with no map:generate|act|mount|redirect-to|call, or src and name attributes,
is illegal
>	  </sch:assert>
>        </sch:rule>
>
>The next example is:
>
>    <!-- Pipeline with map:generate|transform must have serialize
>    <map:pipeline>
>      <map:generate src="sitemap.xmap"/>
>      <map:transform src="../../stylesheets/simple-xml2html.xsl"/>
>    </map:pipeline>
>    -->
>
>This seems fairly straight forward. The following rule seems
>sufficient at first sight:
>
>	<sch:rule context="xmap:pipeline">
>	  <sch:assert test="not(descendant::xmap:generate or descendant::xmap:transform) or
descendant::xmap:serialize">
>	    Pipeline with map:generate|transform must have map:serialize
>	  </sch:assert>
>	</sch:rule>
>
>However, it is not really sufficient, as the only serialize descendant
>of a pipeline might be in an earlier match. For instance:
>
>    <map:pipeline>
>      <map:match pattern="*.html">
>        <map:serialize/>
>      </map:match>
>      <map:match pattern="*.xml">
>        <map:generate src="...somewhere"/>
>      </map:match>
>    </map:pipeline>
>
>would validate by this rule. I can't think of a way to tackle this
>level of generality, but if anyone has suggestions ...
>
>The third example is:
>
>   <!-- Pipeline with component after map:serialize|read|mount|redirect-to|call is
illegal
>    <map:pipeline>
>      <map:read mime-type="text/test" src="sitemap.xmap"/>
>      <map:act type="request"/>
>    </map:pipeline>
>    -->
>
>I do not really know what is supposed to be a component, that is not
>legal. Several examples of map:read followed by map:serialize exist,
>for instance. I have written the following rule:
>
>	<sch:rule context="xmap:pipeline//*[self::xmap:serialize or self::xmap:read or self::xmap:mount
or self::xmap:redirect-to or self::xmap:call ]">
>	  <sch:assert test="count(following-sibling::*[self::xmap:act or self::xmap:transform
or self::xmap:generate or self::xmap:match 
>	                                               or self::xmap:select])=0">
>	    Pipeline with component after map:serialize|read|mount|redirect-to|call is illegal

>	  </sch:assert>
>	</sch:rule>
>
>Which serves for all existing examples, but I don't really know how
>correct it is.
>
>The fourth example is:
>
>    <!-- map:match|select without direct components are illegal
>    <map:pipeline>
>      <map:match pattern="oops">
>        <map:act type="request">
>          <map:parameter name="x" value="x"/>
>        </map:act>
>      </map:match>
>    </map:pipeline>
>    -->
>
>But I don't know what is meant by a direct component here. The
>previous example has map:act as a component, but here it is not to be
>considered a direct component. I am lost. Can anyone please explain?
>  
>



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message