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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
