cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colin Paul Adams <>
Subject Examples of invalid pipelines in lint sitemap
Date Fri, 08 Nov 2002 15:04:05 GMT
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:transform src="../../stylesheets/simple-xml2html.xsl"/>

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

The next example is:

    <!-- Pipeline with map:generate|transform must have serialize
      <map:generate src="sitemap.xmap"/>
      <map:transform src="../../stylesheets/simple-xml2html.xsl"/>

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

However, it is not really sufficient, as the only serialize descendant
of a pipeline might be in an earlier match. For instance:

      <map:match pattern="*.html">
      <map:match pattern="*.xml">
        <map:generate src="...somewhere"/>

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:read mime-type="text/test" src="sitemap.xmap"/>
      <map:act type="request"/>

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 

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:match pattern="oops">
        <map:act type="request">
          <map:parameter name="x" value="x"/>

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?
Colin Paul Adams
Preston Lancashire

To unsubscribe, e-mail:
For additional commands, email:

View raw message